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ABSTRACT 

Trie  oacfctracK  control  structure  is  a  well  Known 
combinatorial  problem  solving  approacn  in  computer  science. 
Tne  strategy  can  be  abstracted  into  a  program  scnema  witft 
slots  for  lower  level  functions  wnicn  is  suitable  for  tne 
automated  syntnesis  of  bac&tracir  programs.  Employing  a 
Known  model  of  program  syntnesis  basea  on  a  problem 
reduction  problem  representation,  two  reduction  rules  are 
developed  for  transforming  a  problem  specification  into  a 
bacKtracs  control  structure  witn  specifications  for  lower 
level  functions.  We  illustrate  tnese  rules  witn  sample 
pro  blems  . 
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I.  INTRODUCTION 


Tne  bacKtracK  control  strategy  nas  developed  into  one  of 
the  major  classes  of  algorithms  since  its  first  appearance 
in  tne  literature  of  computation.  This  nas  been  recognized 
by  many  autnors  and  most  current  textbooks  on  algorithms, 
including  those  by  Ano,  Hopcroft  and  Ullman  [Ref.  lj  and 
Horowitz  and  Sanni  [Ref.  2],  include  substantial  sections  on 
tne  strategy.  Sicill  in  tne  development  of  bacKtract 
aigoritnms  can  be  as  useful  to  programmers  as  their  sieill 
rfltn  otner  general  algorithm  classes,  such  as  the  divide  and 
conquer,  greedy  and  dynamic  programming  control  strategies. 
A  minor  goal  of  tnis  paper  is  to  furtner  refine  Knowledge  of 
the  structural  relationsnips  witnin  a  oactctracK  algoritnm. 

This   expert   Knowledge   of    bacstracK   programming 

techniques  can  also  be  used  in  tne  program  syntnesis 
process.  Tne  problem  reduction  approach  to  program 
synthesis  detailed  in  Smith  [Ref.  3,  4j  employs  reduction 
rules  in  the  form  of  algorithmic  scnemas  and  supporting 
heuristic  Knowledge  concerning  subschema  specification  to 
decompose  a  problem  specification  to  a  series  of  simpler 
specifications.  Program  solutions  to  tnese 
subspecif ications  are  ultimately  composed  via  tne  scnema 
structure  into  a  program  satisfying  the  original 
specifications.   The  major  goal  of  this  paper  is  to   produce 


two  sucn  scnemas  for  tne  baciitracK  control  strategy  and  two 
corresponding  design  met  nods  for  employing  tnese  scnemas. 

Tne  first  discussion  of  bacttracs  by  Walter  [Ref.  5J  was 
a  fairly  general  description  of  a  technique  ttien  in  use  for 
deciding  combinatorial  problems.  Furtner  descriptions  of 
tne  technique,  sucn  as  Golomb  and  Baumert  [Ref .  6J  and 
Bitner  [Ref.  7J  were  oriented  towards  tne  efficiency  aspects 
of  the  strategy.  This  approach  to  tne  study  of  bacKtracic 
algorithms  was  reflected  in  texts  on  combinatorial 
algorithms,  such  as  that  by  Reingold,  Nievergelt  and  Deo 
[Ref.  8J  .  With  this  emphasis  on  the  development  of 
specialized  techniques  for  improving  efficiency  the  study  of 
tne  general  properties  of  the  bacstracfc  class  was 
overlooked.  The  paper  by  Gerhart  and  lelowitz  [Ref.  9j 
reversed  tnis  trend.  They  developed  a  series  of  bacictracic 
scnemas  differentiated  oy  tne  type  of  control  (recursive  or 
iterative)  and  tne  type  of  solution  (first,  all  or  optimal) 
desired.  Tne  empnasis  was  on  tne  development  of  scnemas 
proven  to  be  correct  along  with  general  specifications  for 
the  subschemas  wnicn  would  aid  in  proving  tne  correctness  of 
the  algorithms  developed  to  complete  tne  program. 

This  paper  attempts  to  address  two  perceived  gaps  in  tne 
understanding  of  bacfctracic  algorithms.  The  first  gap  lies 
in  the  development  of  schemas  in  a  notation  suitable  for 
automated  program  synthesis.  This  notation  snouid  anew  for 
simpler  program  verification  techniques  than  those  used   by 


Sernart  and  Yelowitz.  Tne  scnemas  should  also  be  accompanied 
by  heuristics  for  instantiation  of  tne  scnema  to  satisfy  a 
<?iven  problem  specification.  Cnapters  II,  III  and  IV  will 
allress  tnese  concerns  by  describing  tne  program  syntnesis 
system  (Chapter  II),  tne  characteristics  of  a  bacictracK 
algorithm  (Chapter  III)  and  a  bacictracK  prosrram  scnema  and 
associated  design  metnod  (Chapter  17).  The  second  «?ap  lies 
in  the  extension  of  the  bacKtracic  strategy  to  solve  a  class 
of  problems  wnich  have  not  generally  been  solved  by  a 
bacfctract  control  structure  in  tne  past.  Chapter  V  will 
develop  a  scnema  and  associated  design  method  for  searching 
a  solution  ?raph  of  a  problem  with  a  hierarchical 
structure.  Chapter  71  will  conclude  this  paper  and  point  to 
further  areas  of  research. 
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II.  THE  PROGRAM  SYNTHESIS  SYS2EM 

Tne  program  syntnesis  model  for  this  research  is  the 
problem  reduction  approach  as  developed  by  Smith  [Ref.  10, 
11].  This  approach  is  an  attempt  to  formalize  tne 
programming  discipline  of  top  down  design  as  a  nierarcnical , 
problem  reduction  structure.  A  brief  examination  of  this 
model  will  nelp  identify  tne  type  of  Knowledge  required  to 
syntnesize  a  bacttract  program. 

A.   THE  PROBLEM  REDUCTION  MODEL 

The  Key  concept  in  this  model  is  that  program 
development  by  top  down  design  is  a  problem  reduction 
approacn  to  tne  programming  problem.  Top  down  design  is 
accomplisned  tnrougn  successive  refinement  of  a  problem 
specification  into  a  series  of  simpler  subspecif ications . 
These  subspeci f ications  are  related  tnrougn  control 
structures  whicn  direct  control  tnrougn  tne  subprograms.  At 
each  step  of  tne  refinement  process  tne  subspecif ications 
from  the  previous  step  are  furtner  refined.  Tnis  continues 
until  all  are  replaced  by  tne  primitive  constructs  of  tne 
programming  lanpuaee.  The  entire  program  is  then  composed 
from  tne  primitive  language  constructs  and  control 
structures  produced  during  the  refinement  stages. 

A  problem  reduction  problem  solving  approacn  attempts  a 
solution  by  applying  reduction  operators  to  a  problem  goal 
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statement.  These  reduction  operators  decompose  tne  £oal 
into  a  number  of  simpler  subeoals  and  additionally  provide  a 
framewort  for  composing  tne  solutions  to  tne  sub^oals  into  a 
solution  to  tne  original  problem  soal.  Also  required  is  a 
set  of  primitive  operators  which  allow  direct  solving  of  a 
subgoal.  By  successively  decomposing  a  problem  until  a 
primitive  operator  can  be  applied  to  each  subsoal  and  then 
composing  these  solutions  with  the  structure  provided  by  tne 
reduction  operator,  a  solution  to  the  original  problem  is 
found . 

The  analogy  between  problem  red  ction  problem  solution 
and  top  down  design  is  obvious.  The  goal  statement  in  a 
program  syntnesis  system  is  a  formal  specification  of  a 
problem.  A  primitive  operator  of  a  program  syntnesis  system 
is  a  programming  lansruaffe  construct.  Tne  reduction 
operators  include  a  procedure  for  developing 
subspecif ications  (design  strategy  in  Smith  [Ref .  1HJ  ♦ 
design  method  above)  and  a  structure  for  composition  of  tne 
subspecif icati on  solutions.  The  structures  chosen  for  the 
reduction  operators  are  program  scnemas  wnicn  reflect  tne 
different  control  strategies.  Tne  program  synthesis  problem 
is  to  develop  a  program  scnema/desie'n  metnod  pair  wnicn 
allows  syntnesis  of  correct  programs. 

A  simple  example  should  help  illustrate  this  process. 
Suppose  our  specification  requires  tne  selection  of  tne 
maximum  of  two  natural  numbers  given   as   input.    Tne   goal 
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specification  may  loot  lite: 

MAX(A.B)  =  C  sucq  that 
U>=B  <=>  C=AJ   & 
[B>A  <=>  C=BJ 

where  MAX:  (NiN)  ->  N 
This  specification  for  a  function  named  MAX  states  tnat  MAX 
taues  two  natural  numbers  as  input  ana  returns  a  single 
natural  number.  Tne  logic  specification  consists  of  a 
conjunction  of  two  clauses.  Eacn  clause  must  therefore  be 
true  for  tne  output  to  be  correct.  Botn  conjuncts  are 
logical  equivalences,  which  reauires  both  sides  of  tne 
equivalence  to  be  true  or  botn  sides  false  for  the 
equivalence  to  be  true.  Thus  we  tiave  a  specification  in 
wnicn  if  A>=Bt  C  must  equal  A,  and  if  B>A,  C  must  equal  B. 
Tnus  C  must  be  tne  maximum  of  A  and  B.  If  our  programming 
language  nad  a  suitably  defined  function  MAX(X,J),  then  a 
primitive  solution  to  this  goal  could  be  applied.  If  not, 
tne  goal  must  be  further  reduced  to  allow  for  solution.  One 
reduction  rule  wnicn  could  be  applied  is  a  simple 
conditional.  With  this  rule  a  control  scnema  would  oe 
imposed  and  subspecif ications  would  be  developed  for  tne 
schema  slots.   The  schema  may  loos  lice: 

if  P 
then  F 
else  G 

Where  P,  Ff  G  are  functions   the   rule   will   specify.   The 

specifications  produced  by  tne  rule  may  be: 
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P:(A,B)  =  o  sucn  that 

[A>=B  <=>  bj 
where  P:(NxN)  ->  B 

F:A  =  C   sucn  that 

[A  =  CJ 

where  F:N  ->  N 

G:B  =  C   sucn  tnat 

[B  =  CJ 
where  F:N  ->  N 

tfith  these  specifications  P  can   De  directly   solved   by  a 

simple  relational   operator  and  F  and  S  can  De  solved  oy  an 

assignment  operator,  and  tne  final  program  produced  will  be: 

MAX(A,B)  = 
if  A>=B 

tnen  C  <-  A 

else  C  <-  BJ 
return  C 

B.   PROBLEM  SPECIFICATION 

Tne  program   synthesis   system   requires   a   formal 

specification  of   a  problem.   This  formal  specification  is  a 

logical  description  of  the   input/output   relationships   for 

the  program.   The  following  format  will  be  used   to   specify 

problems  in  tnls  paper: 

F:x  =  z  sucn  tnat  I:x  =>  0:<x,z> 
where  F:D  ->  R 

In  tnis  instance,  F   is  tne  name  of  tne  specification  and  me 

:  operator  indicates  function  application. 

There   are   four  components  to  a   formal   specification. 

The   input   condition   I   details   all   Known  properties   of 

objects   input   to   the   program.    If   tne  input  condition 

applied  to  sone  object  x.    is   true,   tnen   tne   program  must 
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produce  tne  specified  output.  In  many  cases  tne  input 
condition  will  be  vacuously  true.  Tne  output  condition  0 
specifies  tne  relations  tnat  are  expected  to  noid  oetween 
tne  input  objects  and  tne  output  objects.  Tne  domain  D 
specifies  tne  data  type  of  input  objects  and  tne  ranee  R 
specifies  tne  data  type  of  output  objects.  Tne  program 
syntnesis  system  will  attempt  to  derive  a  program  F  wnicn 
talces  as  input  an  object  of  type  D  and  produces  as  output  an 
object  of  type  R.  If  tnis  input  object  satisfies  tne  input 
condition  tnen  tne  output  condition  applied  to  tne  input  and 
output  objects  will  be  true. 

C.   THE  PROGRAMING  LANGUAGE 

Tne  target  programming  language  for  tnis  system  is  a 
functional  language  similar  to  Baclrus'  FP  notation  [Ref. 
13 J  .  k  functional  language  provides  several  advantages  to 
tne  program  syntnesis  process.  Tne  most  significant  is  tne 
relative  ease  of  program  verification.  Altnougn  not  a 
trivial  taste,  tne  proof  tecnniques  are  more  manageable  tnan 
tnose  for  procedural  lansua^es.  Tne  principal  reason  for 
tnis  lies  in  the  nature  of  expressions.  A  functional 
program  constitutes  a  single  expression.  Within  tnis 
expression  all  occurences  of  a  name  or  subexpression  nave 
the  same  value.  Thus  the  statement  by  statement  state 
cnanges  within  a  procedural  lan^uasre  wnicn  create  most  of 
the  difficulty  in  program  verification  do  not  exist  with 
functional  programs.   Tnis  permits   an  algebra  of  functional 
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programming,  as  .Bacicus  further  discusses  [Ref.  14J  wnicn 
permits  use  of  trie  language  as  a  proof  tool.  A  second, 
advantage  lies  in  tne  nierarcnic  nature  of  functional 
languages.  Higher  level  functions  are  constructed  from 
lower  level  functions  and  appropriate  comDinlng  functional 
forms.  The  reduction  rules  in  tne  syntnesis  system  are 
actually  methods   for   producing   specifications   for   lower 

level  functions  and  scnemas  wnicn  connect  tne  specifications 
with  the  appropriate  combining  forms. 

A  functional   language  contains  a  set  of  five  components 
[Ref.  15J ,  wnicn  are : 

1.  a  set  of  objects 

2.  a  set  of  functions 

3.  tne  application  operation 

4.  a  set  of  functional  forms 

5.  a  function  definition  mecnanism 

The  functional   language  used  is  fully  described  in  Appendix 
A.  Tne  following  paragrapns  nighiignt  tne  major  differences 
between  .Backus'  notation  and  tne  language  notation  used. 
1«   Set  of  Objects 

The  set  of  objects  in  tnis  language  include  specific 
lata  types.  The  particular  data  types  wnicn  will  be 
necessary  in  this  paper  are  N,  the  natural  numbers,  LIST(N), 
lists  of  natural  numbers,  I,  the  integers  and  B,  the  boolean 
values  true  and  false.  Also  included  is  tne  data  structure 
<>,  sequences  of  objects. 
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2»   Set  of  Primitive  Functions. 

The  set  of  primitive  functions  are  tied  to  the 
various  data  types  and  structures.  A  complete  set  of 
functions  is  given  in  Appendix  A. 

3«   ££e  Ap_p_l isalio n  Op.era.tign 

Function  application  is  enftanced  by  allowing  tne  use 
of  named  parameters  in  botn  tne  application  and  definition 
of  functions.  Tnis  deviates  greatly  from  Backus' 
intentions,  tut  obviates  mucn  of  tne  use  of  selector 
functions  in  data  manipulation.  At  the  least  it  increases 
tne  clarity  of  function  definitions.  A.  further  motivation 
is  the  Knowledge  tnat  efficient  algorithms  [Ref.i6J  exist  to 
extract  named  parameters  from  function  definitions.  A 
declaration  mechanism  is  also  included  to  allow  for 
controlling  name  visibility. 

4»   Z£§  Iu.H£li£2.  P§£i£ili£ll  ^§cnanism 

An  anonymous  function  definition  mecnanism,  similar 
to  the  LISP  lambda  function,  is  included.   The  syntax  is: 

(lambda  <parameter  list> 

{function  definition}) 
(actual  parameter  list) 

This  will  be  most  useful  for  scnema  expression,  as  it  allows 

for  fully  specifying  a  lower  level  function  within  a   nigner 

function.   In  tne  bacctracic  scnema  we  snail  use  tnis  feature 

to  express  a  lower  level  function  in  terms   of  its  component 

functions,  tnereby  directly  expressing  all  components  of  tne 

Dac&traclr  strategy  and  their  relationships. 
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III.  THE  BACKTRACK  CONTROL  STRATEGY 

The  bacKtracff  control  strategy  is  essentially  a 
technique  applicable  to  combinatorial  problems.  A  bacKtrac* 
algorithm  will  conduct  an  uninformed  search  of  a  state  space 
to   select    those   states   which   satisfy   the   problem 

constraints.  The  advantage  of  a  bacKt  racttins"  algorithm  over 
other  uninformed  searcn  techniques  is  that  it  can  employ  the 
problem  constraints  to  prune  tne  state  space  tree,  thus 
reducing  the  amount  of  search  required. 

A.   STATE  SPACE  SEARCH 

K  state  space  problem  representation  attempts  to  define 
a  problem  through  description  of  the  various  states  of  the 
problem  world  and  methods  in  tne  problem  world  for 
transforming  a  given  state  into  a  new  state.  In  tne 
computer  solution  of  state  space  problems  tne  fundamental 
concepts  are  the  symbolic  representation  of  the  relevant 
aspects  of  the  problem  state  and  the  computation  of 
permissible  state  transformations.  These  permissible 
transformations  are  problem  world  related  in  that  they 
represent  transformations  the  problem  world  wouli  permit. 
For  example,  a  permissible  transformation  may  well  lead  to  a 
problem  state  which  violates  a  constraint,  but  is  an 
allowable  action  in  tne  world  being  modelled.  Tne  solution 
technique  most  often  used  to  solve  state  space   problems   is 
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some  form  of  search.  Tne  searcn  commences  at  a  e-iven 
initial  state  and  proceeds  throu^n  a  directed  srapn,.  wfiere 
tne  grapn  nodes  represent  tne  possible  states  and  tr.e  arcs 
represent  tne  permissible  transformations.  Tne  searcn 
terminates  wnen  a  goal  state  is  reacned. 

An  illustrative  example  is  tne  missionaries  and 
cannibals  problem.  In  tnls  problem  we  are  given  an  equal 
number  of  missionaries  and  cannibals  on  a  river  ban*  and  a 
boat  which  can  hold  at  most  two  persons.  Tne  goal  is  to  ^et 
all  missionaries  and  cannibals  to  tne  other  barns:  witnout 
leaving  more  cannibals  than  missionaries  on  eitner  tan*  at 
any  time.  To  represent  this  problem  with  a  state  space 
representation  we  must  identify  the  relevant  aspects  of 
state  and  develop  a  symbolic  representation  for  tnem.  tfe 
must  also  develop  routines  to  compute  allowable 
transformations  between  state  descriptions.  The  solution  to 
tnls  problem  will  be  a  sequence  of  transformations  wnicn 
move  the  missionaries  and  cannibals  from  one  banc  to  tne 
other  and  wnicn  do  not  violate  tne  problem  constraints. 

A  number  of  tecbniques  exist  for  searcnlng  state  space 
?rapns.  Tney  differ  principally  in  the  tecnnique  used  for 
selecting  wnicn  already  visited  state  to  expand,  or  to 
transform  to  a  new  state.  Uninformed  techniques  such  as 
ieptn  first,  breadtn  first  and  generate  and  test  search 
transform  Known  states  in  an  arbitrary  and  fixed  manner. 
The  bacKtracfc  strategy,  as  we  snail  see,  is  an  example  of  an 
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uninformed  search.    An  informed   technique,  sucn  as  best 

first  search,  will  use  some  type  of  Knowledge  to   evaluate 

the  Known  states  and  select  the  most  promising  of  tnese  for 

expansion.   Tne  decision  of  wnetner  to  use  an  informed   or 

uninformed  searcn  is  most  often  a  function   of  tne   proDlem 
and  now  well  searcn  Knowledge  can  be  codified. 

B.   GENERAL  DESCRIPTION  OF  APPLICABLE  PROBLEMS 

BacKtracK  is  suited  for  the  solution  of  combinatorial 
problems  which  exhibit  certain  cnaracte  risti~s .  These 
cnaracteris tics  include  the  ability  to  segment  tne  problem 
into  a  set  of  discrete  but  interrelated  decisions,  a 
solution  structured  as  a  vector  of  decisions,  and  a  set  of 
testaDle  solution  constraints  which  relate  the  decision 
elements . 

1 •   Problem  Characteristics 

Representation  of  a  problem  as  a  set  of 
discrete  decisions  structures  the  problem  into  a  tree  search 
problem.  Each  node  of  the  tree  represents  a  decision  to  be 
made  and  eacn  arc  from  tnat  node  represents  a  different 
alternative  solution.  In  the  missionaries  and  cannibals 
problem  a  node  may  represent  the  decision:  wno  gsts  in  the 
boat  to  go  to  tne  opposite  river  banK?  Eacn  arc  represents 
a  different  alternative:  one  or  two  missionaries,  one  or  two 
cannibals  or  one  missionary  and  one  cannibal.  By  forcing 
this  tree  structure  onto  the  problem,  bacKt  rarKinsr 
algorithms  do  net  nave  to  be  concerned  with  maintenance   of 
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solved  node  lists  or  otner  storage  outside  tne  pata  frorr  tne 
current  node  to  tne  root  of  tae  tree.  In  fact,  tne  state 
space  tree  is  implicit  in  bacttraca:  aigorltams  and  not 
explicitly  stored. 

Representation  of  tne  solution  by  a  vector  of 
decision  solutions  corresponds  directly  to  tae  pata  in  tne 
state  space  tree  explicitly  stored  at  any  time  by  a 
bacKtract  algoritam.  In  oar  state  space  model  tnis  pata  is 
tae  current  state.  Tnis  direct  solution  representatioa 
precludes  a  requirement  to  construct  a  solution  once  tae 
searca  aas  coacluded. 

Tae  problem  defiaed  coastraints  on  solution  element 
relationsnips  allow  bacitracK  algoritams  to  test  tae  current 
sequence  of  decisions  (patn  from  root  to  current  node)  and 
prune  tae  implicit  searca  tree  witnout  explicitly  examining 
all  nodes  of  tae  tree.  Tae  time  efficiency  of  a  bacitracK 
alfforitam,  measured  by  tne  number  of  nodes  examined,  is  a 
function  of  now  well  ronstraiaed  taese  relationsnips  are. 
Tae  tighter  tne  constraints,  tae  less  nodes  will  be 
examined.  Witnout  constraints,  tne  algoritnm  will  exaniae 
all  aodes  of  tae  state  space  tree. 

2.   K  QUEENS  Problem  3ep_resentatioa 

Aa  example  representation  will  illustrate  now  a 
simple  combinatorial  problem  can  be  represented  for  solution 
by  a  bacfctracx  algoritnm.  Tne  problem,  traditionally  used 
to   explain   bacttracic,   is   tne  £  CUEENS   problem.    Simply 
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stated,  tne  £  QUEENS  problem  is  to  find  all  possible  Board 
positions  on  a  KxK  cnessDoard  for  £  queens  sucn  mat  no 
queen  attacks  any  otner  queen.  From  tne  rules  or  cness,  we 
must  find  all  positions  sucn  that  no  two  queens  are  on  tne 
same  row,  on  tne  same  column,  or  on  tne  same  diagonal. 

To  represent  this  as  a  series  of  decisions  we  note 
that  no  two  queens  may  be  on  tne  same  row.  Also,  if  we  are 
to  place  K  queens  on  a  Kx&  board,  there  must  be  at  least  one 
queen  on  eacn  row.  It  follows  that  there  must  be  one  and 
only  one  aueen  on  eacn  row  of  tne  board.  Therefore,  tne 
decision  to  mate  at  level  i  of  the  tree  is  where  to  place 
tne  queen  on  row  i . 

The  solution  vector  returned  will  be  a  path  from  the 
root  to  a  leaf  of  the  tree.  Position  i  of  the  vector  will 
represent  the  positioning  of  the  queen  on  row  i.  Thus  tne 
solution  will  nave  tne  form 

X  =  (x(l)  ,  x(2),  ...  ,  x(K) ) 
wnere  eacn  x(i)  is  tne  position  (column  number)  of  the  queen 
on  row  i . 

Tne  constraint  relationships  can  also  be  determined 
from  the  rules  of  cness.  These  constraints  reflect  tne 
facts  tnat  no  two  queens  can  be  on  the  same  column  or 
diagonal.  To  express  the  column  constraint  in  a  computable 
form  we  note  tnat  our  representation  would  depict  two  queens 
in  tne  same  column  as  two  elements  of  tne  solution  vector 
Having  the  saiie  value.    rfe   can   restrict   this   with   tne 
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constraint : 

column  constraint 

FOR  Ml    i(l)  ,x(j)  IN  X 

[i*J  =>  x(i)*x(j)] 
Tne  diagonal  constraint  is  a   little  more  difficult 
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queens  are  on  tne  same  diagonal  if  tneir  row  distance  is  tne 

same  as  their  column  distance.   For  example,  queens   at   row 

and   column  positions  (l  4)   and   (3  6)   are  on   tne   same 

diagonal  as  are  queens  at  positions   (l  4)  and  (3  2).  We  can 

thus  subtract  the  queens'  row  numbers  and  column  numbers  and 

then  compare  their  absolute  values  to  determine  if  they  are 

on   tne   same  diagonal.    This   gives   us   the   diagonal 

constraint : 

diagonal  constraint 

FOR  ALL  x(i),x(j)  IN  X 

[i*J  =>  abs(i-j)*abs(x(i)-x(j) ) 

One  final  constraint  identifies  a  path  as   a  solution  and 

thus  may  be   termed   a  solution  constraint.   This  constraint 

is  identified   by   the  fact  that  I    decisions  must  be  made  to 

place   K   queens   on   tne   board.    k      computable   solution 

constraint   is   tnus   lengtn(X)   =   £.   The   complete 

representation  is  given  in  Figure  1. 

C.   GENERAL  DESCRIPTION  OF  THE  STRATEGY 

BacKtracfc  is  best  defined  as  an  uninformed,  exhaustive, 
depth  first  tree  search  strategy.  The  strategy  is 
uninformed,  in  that  it  does  not  employ  problem  specific 
Knowledge  about  how  to  searcn  for  a  solution  state.  It  is 
exhaustive  in   that  it  will  implicitly  or  explicitly  examine 
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all  possible  solution  states  as  it  executes.  It  is  a  tree 
searcn  strategy  because  it  implicitly  structures  tne  problem 
into  a  tree  wnicn  represents  solution  states  by  a  patn  from 
tne  root  to  a  leaf.  It  is  a  deptn  first  strategy  because  it 
fully  examines  a  subtree  defined  oy  one  alternative  before 
it  begins  examination  of  tne  next  alternative. 


DECISION  STRUCTURE 

decision(i)  =  column  placement  for  queen  on  row  i 

SOLUTION  STRUCTURE 

<X>  wnere  eacn  X  =  (x(l),  x(2),  ...  ,  x(K)) 

wnere  x(i)  =  column  number  for  queen  on  row  i 

CONSTRAINT  STRUCTURE 
element  constraints 

FOR  Ml   x(l)  ,x(  j  )  IN   X 
[i*j  =>  x(i)*x(j)J 
[i*j  =>  abs(i-j^abs(x(i)-x(jnj 
[1  <=  x(i)  <=  KJ 
solution  constraint 
lengtn:X  =  £ 


FIGURE  1 
£  QUEENS  Problem  Representation 

A  bacfctracK  strategy  attempts  to  construct  a  solution 
vector  one  element  at  a  time.  After  deciding"  on  one 
element,  tne  strategy  will  expand  tnls  solution  one  element 
furtner.  If  tne  strategy  determines  no  expansion  is 
possible  and  a  complete  solution  nas  not  been  acnieved  tnen 
it  will  bacfftracK,  cnange  its  most  recently  made  decision, 
and  try  to  expand  tne  new  partial  solution. 

To  implement  tnis  strategy,  a  bacKtraca:  aleoritnm  taKes 
as   an   input  parameter  a  description  of  tne  patn   from  trie 
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root  of  tne  state  space  tree  to  the  node  beine  expanded. 
The  algorithm  will  expand  tnis  node  by  creatine  descriptions 
of  all  possible  paths  from  the  root  through  the  expanded 
node  with  leneth  equal  to  one  greater  than  tne  parameter 
patn.  Tne  algorithm  will  then  examine  these  new  paths  in  an 
arbitrary  order.  Tnis  examination  first  tests  the  path  for 
a  solution  and  returns  tne  patn  if  it  is  found  to  be  a 
solution.  If  not  a  solution,  it  tests  for  any  violation  of 
a  predefined  subset  of  tne  problem  constraints.  If  a 
violation  is  found,  the  algorithm  determines  no  solution  can 
be  found  with  further  exploration  and  terminates  search  on 
this  path  and  all  possible  extensions.  If  tnere  are  no 
constraint  violations,  the  path  is  recursively  expanded  to 
searcn  for  a  solution  deeper  in  tne  tree. 

Recursion  is  the  natural  form  of  expression  for 
bacfrtracK  algorithms.  Using-  standard  program 
transformations  Horowitz  and  Sahni  IRef.  1?J  and  Gertiart  and 
Telowitz  [Ref.  19]  nave  developed  iterative  bacKtracxins 
procedures  from  their  recursive  algorithms.  This  paper, 
since  it  is  not  concerned  with  efficiency  issues,  will 
develop  algorltnms  and  scnemas  in  recursive  notation  and 
leave  for  later  program  transformation  worn:  tne  translation 
into  iterative  notation.  Vitn  tnis  in  mind.  Figure  2  gives 
a  simple  bacfctracfc  function  in  a  procedural  notation. 

The  efficiency  of  a  bacstracfc  algorithm  principally 
depends  on  now  tne  patn  element  constraints  contained  in  tne 
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predicate  FEASIBLE  are  defined.  Tne  pruning  efficiency  of 
tfte  preiicate  is  directly  related  to  tne  decree  of 
constraint  being  tested.  Tne  more  constraining  tne 
relationships,  tne  more  pruning  will  be  accomplisned .  As 
iiscussed  above,  tne  pruning  constraints  will  often  be  a 
subset  of  tne  total  problem  constraints.  For  these  reasons, 
a  good  neuristic  is   required  for  selecting  tne  appropriate 

constraints  if  a  good  bacirtrac&ing  algorithm  is  to  be 
developed  by  a  programmer  or  an  automated  synthesis  system. 
A  syntnesis  design  method  based  on  such  a  neuristic  is  thus 
desirable. 

The  computation  of  tne  predicate  FEASIBLE  nignlignts  one 
further  characteristic  of  the  strategy.  The  relationships 
expressed  in  the  predicate  often  involve  data  about  tne  path 
elements.  This  data  must  be  visible  to  the  predicate,  wnicn 
normally  implies  extensive  parameter  passing  at  each  call  of 
tne  function.  The  data  relevant  to  each  element  of  tne  path 
is  very  often  static,  nowever.  The  data  can  be  seen  as 
properties  of  tne  separate  elements,  and  tne  constraining 
relationships  as  relationships  between  tne  elements' 
properties.  For  this  reason,  many  backtracking  algorithms 
establish  these  properties  as  global  data,  which  can  be 
accessed  from  any  level  of   tne  recursion. 


25 


PROBLEM  (PARM_LIST)   <-   BACKTRACK  (NIL) 

wnere 

FUNCTION  BACKTRACK  (PATH)    is  defined  as 

ALTERNATIVE_SET  <-  GENERATE  (PATH , PARM_LIST ) 

/*  generate  is  a  function  wfticn  will  return  all 
extensions  to  PATH  */ 

SOLUTION_SET  <-  {}; 

FOR  P  IN  ALTERNATIVE_SET  DO 

IF  SOLOTION  (P) 

THEN  SOLUTION_SET  <-  SOLUT10N_SET  U  {P> 
/*  solution  is  a  predicate  wnicn  returns 
true  if  tne  parameter  is  a  solution 
to  tne  problem  */ 
ELSE 

IF  FEASIBLE  (P) 

THEN  SOLUTION  SET  <- 

SOLQTION_SET    U   BACKTRACK    {?); 
/*   feasible   is   a   predicate   wnicn    return? 
true   if    tne    parameter   can    be   expanded   */ 


END  for; 

RETURN    SOLUTION_SET; 
END    BACKTRACK 


FIGURE    2 
General    Bacstracfc   Function 

Tne   ale'oritnm   described   above    is   a   simple   description   of 

a      bacirtracfc     strategy  wnicn   returns   all      solutions      in     tne 

problem        defined      state      space.        Two      otner     variants        of 

bacttracK     often     arise.      Tne   first   variant     is     a      strategy 

wnicn      returns      only      tne    first      solution     discovered.        Tne 

second      variant    returns    only   tne    best    solution      encountered, 

wnere      tne      solutions      nave      been      ordered      by   seme      scoring 
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function.  Botn  of  tnese  variants  require  additional  control 
features  wnicn  complicate  tne  basic  bacictracir  strategy  and 
will  not  be  further  discussed  in  tnis  paper.  For  tr.ose 
interested,   Gernart  and  Yelowitz  [Ref.  19J  provide   furtner 

discussion  of  tnis  topic. 
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IV.  A  BACKTRACK  REDUCTION  RULE 

A  reduction  rule  for  Implementing  a  DacKtracK  algorithm 
nas  two  components,  tne  program  scnema  and  tne  design  method 
for  subscnema  specification.  Tnis  chapter  develops  a  scnema 
for  a  simple  bacirtracff  algorithm  witn  slots  for  three 
subalfforithms.  A  design  metnod  is  tnen  presented  for 
reducing  the  problem  specification  into  subaigoritnm 
specifications.  Tne  metnod  is  based  on  an  examination  of 
the  required  relationships  of  the  three  suoal^oritnms .  Two 
problems  are  then  examined  to  illustrate  the  application  of 
tne  reduction  rule. 

A.   SCHEMA  DEVELOPMENT 

In  developing  a  program  scnema  one  approach  is  to 
describe  completely  tne  expected  input  to  tne  scnema,  tne 
desired  output  from  tne  scnema  and  tne  series  of 
transformations  on  tne  input  tne  scnema  is  required  to 
perform  to  produce  the  output.  These  transformations  can 
then  be  translated  into  lower  level  functions  connected  by 
tne  language  combining  forms.  Tne  following  paragraphs 
derive  a  scnema  in  the  desired  functional  language  using 
this  procedure. 

1 •   The  Exne c ted  Input 

From   the   general   discussion   of    the   DacKtracK 
strategy  (see  page  23)  we  can  describe   tne  expected   input 
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and  its  salient  characteristics.  Wnen  a  bacfctracn:  function 
is  invoiced  it  is  passed  one  parameter,  a  vector 
representation  of  a  partial  solution  to  the  problem.  We 
will  call  this  vector  PATH,  since  it  is  a  path  from  tne  root 
of  the  state  space  tree  to  the  last  node  (last  element  of 
the  vector)  examined.  PATH  is  of  unknown  length,  since  the 
function  is  called  at  every  level  of  tne  state  space  tree. 
A  null  PATH  can  also  exist,  which  indicates  no  decisions 
nave  yet  been  made.  This  is  tne  problem  state  wnen  tne 
initial  invocation  occurs. 

Altnougn  tne  length  of  PATH  is  unknown,  tnere  are 
characteristics  wnicn  can  oe  inferred.  Tne  most  significant 
is  that  PATH  nas  been  determined  not  to  be  a  solution.  If 
the  previous  invocation  of  tne  function  nad  determined  that 
PATH  was  a  solution  then  tne  function  would  nave  terminated 
prior  to  the  recursive  invocation  we  are  concerned  with.  A 
second  characteristic  is  that  PATH  meets  tne  test  of  the 
predicate  feasible.  A  major  assumption  of  this  design 
method  is  tne  conclusion  that  although  PATH  may  not  satisfy 
all  tne  output  conditions  required  by  the  problem 
specification,  it  satisfies  a  major  subset  of  tne 
conditions.  Furthermore,  there  is  reason  to  expect  tnat  an 
expansion  of  PATH  will  eventually  satisfy  all  tne  output 
conditions.  The  current  bacitraclc  invocation  must  therefore 
searcn  for  all  such  expansions. 
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Another  input  issue  concerns  the  problem  lata  which 
will  be  required  by  the  lower  level  functions.-  The 
assumption  made  in  tne  development  of  this  paper  is  teat 
this  data  will  be  made  global.  Figure  2  (see  page  27) 
demonstrates  how  this  is  accomplished.  All  program 
specifications  developed  will  declare  this  data  as  a 
parameter  to  the  program,  then  declare  the  BACKTRACK 
function  and  lower  level  functions  at  the  same  scope  level, 
providing  tne  required  visibility.  The  alternative  is  to 
declare  tne  data  as  input  to  BACKTRACK  and  pass  it  as  a 
parameter  to  every  recursive  call  of  the  function.  In  the  K 
QUEENS  example  tne  only  data  is  the  value  of  K.  The  cost  of 
passing  tnis  parameter  will  be  minimal.  In  other  examnles, 
such  as  the  Processor  Sequencing  Problem  we  discuss  later, 
the  data  is  mucn  more  extensive  and  tne  parameter  passing 
costs  are  higher.  In  any  case,  it  is  simpler  to  consiier 
this  data  as  global  and  not  be  concerned  with  the  mecnar.ics 
of  creating  parameter  lists. 

The  output  from  a  bacxtracx  algorithm  is  also  a 
path  or  list  of  patns.  These  paths,  in  vector  form, 
represent  all  possible  solutions  to  tne  problem.  Each 
invocation  of  tne  bacxtracic  function  examines  a  subtree  of 
tne  state  space  tree  to  search  for  an  extension  to  PATH 
wnicn  terminates  in  a  solution.  Tne  snorter  PATM  is  tne 
leeper  the  subtree  examined  will  be.   In  any   subtree   tnere 
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is    a    possibility   of    zero,      one      or   more   solutions    wnicn  will 

be    returned    to      the      invocation   examining    that    subtree-.  The 

bacfctracfc      function     must      compose        these        separate  patn 
solutions    into    a    list    of    subtree   solutions. 

3»   IHEUI  Transformations 

The  input  transformations  are  also  apparent  from 
the  strategy  description  (see  pase  23).  There  are  three 
transformations  to  perform.  The  first  of  these  is  an 
expansion  of  the  current  partial  solution  by  one  additional 
decision.  At  the  simplest  level  this  transformation  must 
produce  a  set  of  all  paths  which  are  possible  expansions  of 
PiTI.  Eacn  path  in  this  set  represents  expansion  of  the 
partial  solution  by  one  additional  decision  element.  Saca 
possible  decision  is  represented  by  a  corresponding  element 
in  the  set.  The  result  of  this  transformation  is  a  set  of 
paths  to  be  examined. 

The  second  transformation  is  to  execute  a  series  of 
conditional  tests.  These  tests  perform  tne  examination  of 
each  path  produced  by  the  first  transformation.  The 
significant  characteristic  of  the  strategy  is  tnat  the  tests 
and  resulting  action  are  completed  for  eacn  patn  before  any 
processing  besrins  on  any  otner  patn.  We  will  can  tne  patn 
under  consideration  TEST_PATH.  The  tests  and  actions  can  be 
subdivided  into  two  sets.  The  first  set  tests  for  a 
solution.  If  a  solution  is  discovered,  tne  action  is  to 
return  TEST  PATH.  If  the  first  test  fails,   the  second   set 
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tests  for  feasibility  of  expansion.  If  this  test  deciles 
expansion  is  feasible,  tne  bacKtracs  function  is  recursively 
called  with  TEST_PATH  as  the  parameter.  If  the  test  fails 
no  further  expansion  is  feasible  and  the  nil  path  is 
returned  to  signify  no  solution  is  found. 

Tne   final  transformation  is  required   to   eliminate 
the  nil  patns  in  tne  solution  once  all   expansions  neve  teen 
examined.   After  this  transformation   is  complete,  the  value 
returned  will  consist  of  a  list  of  solutions. 
*•   S enema  Translation 

Translation  into  a  program  schema  requires  grouping 
desired  transformations  into  lower  level  functions  and 
specifying  the  appropriate  functional  forms  for  relating  tne 
inputs  to  and  outputs  from  tne  functions.  Tne  ability  to 
separate  the  bacKtracfc  strategy  into  three  transformations 
of  the  input  implies  that  we  can  define  three  lower  level 
functions  to  perform  the  transforms.  The  following 
paragraphs  develop  these  three  functions  and  the  proper 
combining  forms. 

The  first  transformation  operates  on  tne  input  to 
the  schema,  the  parameter  PATH.  Tnis  allows  specification  as 
a  direct  function  application  to  tne  parameter.  The  output 
of  this  application  is  to  be  a  list  of  all  patns  wnlcn  are 
expansions  of  PATH.  Since  the  operation  is  to  venerate  all 
possible  expansions,  we  will  name  tnis  function  GENERATE.  In 
our  language  notation  tnis  is:  GENEHATErPATH . 
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Trie  second  transformation  operates  on  tne  output  of 
the  function  GENERATE.  Its  metnod  is  to  operate  on  an 
element,  return  a  value,  operate  on  tne  next  element,  return 
a  value  and  continue  until  tne  list  provided  by  GENERATE  is 
exnausted.  Tnis  operation  is  clearly  an  example  of  tne 
APPLY-TO-ALL  functional  form  available  in  our  language. 
Since  tne  operation  is  a  test  of  eacn  element  of  tne  list  we 
will  name  trie  function  TEST.  In  our  lan^ua^e  notation  tnis 
is: 

o^TEST  (GENERATE:  PATH) 
Ve  fcnow  more  about  tne  behavior  of  tne  function  TEST, 
However.  TEST  is  a  conditional  function  with  two 
predicates.  We  can  furtner  specify  TEST  within  tne  scnema 
by  employing  this  Knowledge.  Tne  first  predicate  is  a 
solution  test.  The  resulting  action  is  to  return  tne  path 
if  the  predicate  holds.   In  our  language  this  is: 

SOLUTION :TEST_PATfi  ->  ID :TEST_PATH; 
The  second  test  is  a  cnecfc  for  feasibility.   The  action  is 
to  recursively  call  tne  bacKtracs  function  witn  tne  path  as 
parameter.   This  can  be  expressed  in  our  language  as: 

FEASIBLE :TEST_PATH  ->  BACKTRACK :TEST_PATH J 

The  final  action  of  tne  function  is   to  return  nil.   The  use 

of  an  anonymous  function  definition  will  allow  definition  of 

TEST  witnin  the  schema  as  follows: 

oUlambda<TEST  PATH> 

{  (SOLUTION :TEST  PATH  ->  I£:TEST  PATH; 

FEASIBLE :TEST_PATH  ->  3ACKTRAC"K:TEST_PATH ; 

NIL)}) 

(GENERATE :PATH) 
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Tne  final  transformation  eliminates  all  null  lists 
in  the  list  returned  by  tne  partial  scnema  aoove.-  Tne 
appropriate  lower  level  function  and  combining  form  already 
exist  in  our  lan^ua^e.  Tne  functional  form  INSERT  will  move 
trie  function  APPEND  through  tne  list  and  eliminate  all  null 
list  occurences.  All  that  is  required  is  to  compose  tnis 
function  and  combining  form  onto  tne  partial  scbema  to 
produce  tne  oacttracic  scnema  of  Figure  3. 


BACKTRACK:PATH 
/APPEND 
(<X  (lambda<TEST_PATH> 

{  (SOLUTI0N:TEST_PATH  ->  I  D:  TEST_?ATH,* 

FEASIBLE:TEST_PATH  ->  BACKTRACK :TES T_PATK ; 
NIL)}) 
(GENERATE:PATH)  ) 


FIGURE  3 
BacKtract  Program  Scnema 

B.   DESIGN  METHOD  FOR  SUBSCHEMA  SPECIFICATION 

The  schema  developed  above  is  only  one  component  of  tne 
required  reduction  rule.  Also  necessary  is  a  lesion  metnod 
for  specifying  the  lower  level  functions  GENERATE,  SOLUTION 
and  FEASIBLE.  A  rule  for  derivation  of  these 
subspecif ications  must  be  based  on  tne  expected  input  and 
output  of  tne  functions  and  tne  reiati onsnips  between  the 
functions  wnicn  tne  schema  exploits  to  solve  tne  problem. 
Tne  reduction  rule  developed  in  tne  following  paragraphs 
builds  from  these  relationships.  The  rule  provides  a 
specification  schema   for  eacn  for  eacn  lower  level  function 
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and  a  method  for  instant  latins:  tne  scnemas  for  a  ?iven 
problem  instance.  Tne  metnod  is  a  pattern  matcninp  process 
wnicn  replaces  references  to  tne  problem  specification  in 
tne  scnemas  wi tn  tne  referenced  components  of  tne  problem 
specification.  In  developing  tne  scnemas  tne  notation  usea 
below  is  tne  same  as  tne  problem  specification  notation, 
witn  two  additions:  Capital  letters  refer  to  tne  components 
of  tne  specification  and  lower  case  letters  refer  to  tne 
function  or  problem  specification.  Tnus  Op  refers  to  tne 
output  condition  of  tne  problem  specification,  wnile  Os ,  Of 
and  Off  refer  to  tne  output  conditions  of  tne  functions 
SOLUTION,  FEASIBLE  and  GENERATE  respectively. 
1 .   GEN  ER ATE  Sp.ec.if.ica.Iion  5 £h £oa 

To  derive  a  general  neuristic  for  specifying  the 
GENERATE  function  we  need  to  closely  examine  tne  output 
requirements  for  tne  function.  Bac£trac£  requires  GENERATE 
to  produce  all  single  decision  extensions  to  PATH.  It  is 
significant  tnat  GENERATE  is  tne  only  function  in  tne  scnema 
wnicn  produces  output.  Eacn  element  of  tnis  output  is  a 
potential  solution.  Tne  implication  is  tnat  GENERATE  must 
perform  all  computation  required  to  const  uct  a  decision 
element  and  append  it  to  PATH.  Tnis  computation  may  require 
incorporation  of  constraints  from  tne  problem  output 
condition.  Tne  K  QUEENS  problem  provides  a  simple  example. 
In  tnis  problem  tnere  is  a  direct  constraint  on  tne  value  of 
tne  decision  alternatives,  tnis  bein?  tnat  tne  column  number 
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for  each  decision  must  be  between  one  and  K. .  Failure  to 
include  this  constraint  in  GENERATE  may  result  in  the 
production  of  an  infinite  sequence  of  patn  extensions. 

A.  heuristic  to  support  this  reasoning  can  be 
designed.  If  a  constraint  exists  which  places  direct 
restrictions  on  tne  computed  value  of  a  decision  element 
tnen  this  constraint  should  be  included  in  the  specification 
for  GENERATE.  Vnat  constitutes  a  "direct  restriction"  is  not 
well  formulated,  but  two  general  principles  are  offered.  If 
a  constraint  restricts  a  decision  element  by  a  specified 
relation  to  constant  values,  tnen  this  is  a  direct 
restriction.  The  K  QQEENS  constraint  above  falls  in  tnis 
category.  Secondly,  if  a  constraint  is  formulated  as  an 
equality  between  a  decision  element  and  a  computable  value, 
tnen  the  constraint  directly  restricts  the  decision.  We 
will  show  an  example  of  this  later.  On  a  more  general  note, 
the  issue  of  which  function  to  include  constraints  in  is  a 
major  point  of  concern  to  algorithm  designers  and  is  further 
addressed  in  the  section  on  schema  limitations. 

Tnere  are  otner  output  conditions  for  tne  GENERATE 
function.  If  GENERATE  is  to  produce  single  decision 
extensions  to  PATH  then  the  length  of  each  element  of  tne 
output  must  be  one  greater  tnan  tne  length  of  PATH.  Also, 
eacn  element  of  the  output  minus  its  last  decision  is  equal 
to  PATH.  A.  clean  symmetry  exists  between  these  constraints. 
We  nave  restricted  the  size   of   each  element  of  tne  cutnut. 
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the  value  of  trie  last  decision  of   each   element,   and   trie 

values  of  tne  rest  of   the  decisions.   Tnis  suggests  a 

completeness  in   tne   specification.    Trie   complete   output 

condition  0^  can  be  expressed  as: 

Os   =  FOR  ALL  TEST_PATH   IN   PATH_LIST 

[lengtn(TEST_PATH)  =  l+lengtn:PATH  & 
tlr(TEST_PATH)  =  PATE  & 
Op?(last(TEST_PATH))J 

where  Opg  =  subset  of  Op  which  directly 
restricts  a  decision 

There  are  certain  conditions  Known  to  oe  true  of  the 

input.   As   discussed  in  the  paragraph  on  schema  development 

PATH  is  Known  to  be  feasiDle.    Tnis  fact  may  &e  used  by  the 

synthesis  system  and  needs  to  be   represented  as  an   input 

condition.   The  specification  input  condition  is  tnus  : 

FEASIBLE (PATH) 

To  derive  the  domain  and  ran^e  of  GENERATE  we   need 

to  examine  tne  relationships  between  the  input  and  output  of 

tne  function  anc  those  of  the  problem.  Generate  accepts  as 
input  a  path  representation  for  which  it  is  to  generate 
allowable  expansions.  Although  not  a  solution,  PATH  is  the 
proper  type  of  a  solution.  Ve  can  discover  the  solution 
type  by  examining  tne  range  of  tne  problem.  The  problem  is 
to  produce  a  seauence  of  solutions.  The  range  of  tne 
problem  is  tnus  a  sequence  of  tne  desired  type.  Giver  a 
problem  ran^e  of  <Y>,  which  signifies  a  sequence  of  oojects 
of  type  I,  where  I  is  a  lan^uasre  type  we  can  extract  Y  as 
tne  domain  of  GENERATE.  The  function  must  output  a   sequence 
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of  objects,  each  of  wnicn  is  a  potential   solution.   Tills  is 

tie  same  output   type  as  tne  problem  and  the  pro ciem. range 

can  be  substituted  for  tne  range  of  GENERATE.  Tnis   produces 

a  domain  and  range  specification  of: 

Dg  =  Y  wnere  Rp  =  <Y> 
Rg  =  Rp 

Tne  complete  specification  scnema  is  given  in  Figure  4. 

2.   SOLUTION  Sp.eci_ficatl.on  Scnema 

Tne   function  SOLUTION  is  tne  simplest  cf  tne   lower 

level  functions  to  specify  since  it  relates  directly  to   tne 

entire  problem  specification.   SOLUTION   is  a  function  wr.icn 

accepts  a  patfl  representation  as  input  and  returns  a  boolean 

value.   Tne  representation   SOLUTION   tests  is  tne  same  type 

as  tne  elements  of  tne  problem  domain.    In   tne  X  QUEENS 

problem,  for  example,  tne  problem   ran^e   is   <1IST(N)>.   We 

want  tne  program  to  produce  a  sequence  of   lists  ,  wnere  eacn 

list  is  a   solution.    The  corresponding  domain  for  SOLUTION 

is  simply  LIST(M).  Since  the  function   is   a   predicate,   it 

must  return  a  boolean  value.   Tne  domain  and   ran#e  can  thus 

be  specified  as: 

Ds  =  Y  wnere  Rp  =  <Y> 
Rs  =  B 

To  derive  the  input  and  output  specifications  we   note   tnat 

SOLUTION  must  return  true  when  the  problem  output  conditions 

applied  to  tne  parameter  TEST_PATH  are  true  and  must   return 

false  wnen   tne  problem  output  conditions   applied   to   tne 

parameter  are  false.   Tnis  can  be   expressed   as   a   logical 
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equivalence  between  tne  boolean  value  returned  and  tne 
problem  constraints  applied  to  tne  parameter  TEST_?ATE. 
Since  some  of  the  constraints  may  be  included  in  GENERATE, 
we  need  only  include  tne  subset  not  in  GENERATE.  Tne  input 
condition  follows  from  tne  input  condition  to  GENERATE. 
Since  tne  input  to  GENERATE  is  Known  to  be  feasible,  the 
input  to  SOLUTION  minus  tne  last  element  must  be  feasible. 
Tne  input  and  output  conditions  may  be  expressed  as: 

Is  =  FEASIBLE(tlr:PATH) 
Os  =  Ops(TEST_PATH)  <=>  b 

where  Ops  =  subset  of  Op  not  included 
in  GENERATE  specification 

The  complete  specification  schema  is  ^iven  in  Figure  4. 
3.   EEASI2LE  Specif  Italian  Schema 

The  specification  of  FEASIBLE  is  more  difficult  than 
that  for  SOLUTION  because  the  feasibility  test  is  the  less 
constraining  of  the  two.  An  assumption  of  tnis  lesion 
metnod  is  tnat  FEASIBLE  is  a  relaxation  of  the  constraints 
represented  by  SOLUTION.  One  rule  for  relaxing  restrictions 
is  to  eliminate  one  or  more  expressions  within  a  conjunctive 
statement  of  constraints.  We  atte-npt  to  develop  a  neuristic 
for  identifying  which  conjunct  or  ~onjuncts  of  the 
constraints  stated  in  tne  problem  output  conditions  to 
include  in  tne  feasibility  test. 

Tne  bacitracfc  scnema  expects  certain  cnaracteris ti cs 
of  the  path  being-  investigate!.  A  path  which  is  feasible 
yet  not  a  solution  fails  to  meet  one  or  more  of   tne   output 
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conditions.  However,  it  is  feasible  that  an  expansion  of 
tne  patn  nay  meet  ail  tne  output  conditions.  A-  pain 
determined  to  be  unfeasible  also  fails  to  meet  one  or  more 
of  tne  output  conditions.  Tne  difference  is  tnat  an 
unfeasible  patn  will  never  meet  all  tne  output  conditions, 
no  matter  wnat  sequence  of  decisions  is  appended.  If  we  can 
specify  tne  type  of  condition  wnicn,  wnen  failed  by  a 
partial  solution  will  also  be  failed  Tiy  any  extension  to 
tnat  partial  solution,  tnen  tnis  Knowledge  can  be  aided  to 
our  reduction  rule. 

A  neuristic  can  oe  formulated  to  express  tnis 
Knowledge.  A  constraint  wnicn  addresses  tne  solution  as  a 
wnole  is  not  of  tnis  type.  If  tne  patn  as  a  single  entity 
fails  a  condition,  tnen  any  expansion  to  tne  patn  produces  a 
different  entity,  and  may  pass  tne  condition.  A  constraint 
wnicn  limits  tne  relations  between  tne  parts  of  tne  solution 
is  of  tnis  type,  nowever.  If  a  partial  solution  exniDits  a 
conflict  between  two  elements  tne  same  conflict  will  exist 
no  matter  wbat  subsequent  elements  are  appended  to  tne 
path.  Tne  conclusion  is  tnat  tne  appropriate  constraints 
are  a  suoset  of  tne  problem  output  conditions  and  can  ce 
selected  by  an  heuristic  process  wnicn  retains  only  tnose 
constraints  wnicn  relate  elements  of  tne  proposed  solution. 
Tne  input  and  output  conditions  can  be  expressed  as: 
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If  =  FEASIBLE(tlr:PATH) 
Of  =  Opf (TEST_PATH)  <=>  b 

wnere  Opf  =  all  conjuncts  of  Op  fcrfticfc 

relate  elements  of  TEST_PATH 
and  are  not  in  GENERATE 

Since   FEASIBLE  is   a   component    of   the    sane 

conditional   expression  as  SOLUTION,  tne  domain  remains   tne 

same.   Since  it  is  also   a  predicate,  tne  rane*e  remains  tne 
same . 

Cf  =  Y  where  Rd  =  <Y> 
Rf  =  E 

The    complete   specification   scnema    is   given    in   Fisrure    4. 

C.   THE  K  QUEENS  PROBLEM 

Our  first  example  to  illustrate  tne  use  of  tnis 
reduction  rule  will  be  tne  K  QUEENS  problem  discussed 
earlier.  The  format  to  be  followed  in  presenting  tnis  and 
later  problems  will  be  to  represent  the  problem  with  tne 
structure  in  Figure  1,  develop  a  formal  specification  of  the 
problem,  and  tnen  apply  tne  reduction  rule  of  tne  two 
previous  paragrapns.  Tne  output  will  be  a  program 
satisfying  toe  problem  in  the  form  of  tne  baclctraclc  program 
scnema  witn  formal  specifications  for  tne  lower  level 
functions. 
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GENERATE  SPECIFICATION  SCHEMA 

GENER4TE:PATH  =  PATH  LIST   sucn  tnat 
FEASI3LE:PATK  => 

FOR  ALL   TEST  PATH   ELEMENT  OF   PATH_LIST 

[lengtnTTEST_PATH)  =  1+lengtft ( PATH )  £ 
tlr(TEST_PATH^  =  PATH  ± 

Opg(last(T£ST_?ATH) )] 

wnere   GENERATE:!  ->  Rp  sucn  tnat  Rp  =  <Y> 

and   Ope  =  subset  of  Op  sucn  tnat  all  conjuncts 

of  Op  wnicn  directly  restrict  decision 
elements  are  in  Ope 

Heuristic:  To  identify  Op  elements  for  Ope.  select 
tnose  in  wnicn  eitner 

1)  a  single  decision  element  is  restricted 
by  constant  values   OR 

2)  a  single  decision  element  is  restricted 
by  an  equality 

SOLUTION  SPECIFICATION  SCHEMA 

SOLUTION: TEST  PATH  =  o  sucn  tnat 

b  <=>  [FEASIBLE(tlr:PATH)  =>  Ops (TEST_PATH ) J 

wnere   SOLUTION:*.  ->  E   sucn  tnat   Rp  =  <y> 

and  Ops  =  suoset  of  Op  sucn  tnat  all  conjuncts 
not  in  Opg  are  in  Ops 

FEASIBLE  SPECIFICATION  SCHEMA 

FEASIBLE:TEST  PATH  =  b   sucn  tnat 

b  <=>  [?EASIBLE(tlr:PATH)  =>  Opf (TEST_PATH )] 

wnere   SOLUTION:!  ->  B   sucn  tnat   Rp  =  <I> 

and   Opf  =  subset  of  Op  sucn  tnat  all  conjuncts 
wnicn  relate  decision  elements  and 
not  in  Opg  are  in  Opf 


FIGURE  4 
Reduction  Rule  Specification  S enemas 

Tne  required  problem  representation  was  developed  in 
Figure  1  (see  paee  24). 
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2«   Problem  Specification 

The  components  of  the  forrral  problem  specification 
nay  be  extracted  directly  from  trie  problem  representation. 
Tne  domain  of  tne  problem  is  tne  type  of  tne  variable  input 
parameter.  For  tne  K  QUEENS  problem  tne  variable  parameter 
is  K,  tne  natural  number  denoting  tne  size  of  tne 
cnessboard.  Tne  domain  is  tnus  N,  tne  natural  numbers.  Tne 
ranee  of  tne  problem  is  tne  type  of  tne  solution  structure. 
For  tne  K  QUEENS  problem  tne  solution  is  expressed  as  a 
sequence  of  lists  of  natural  numbers.  Eacn  list  represents 
one  solution  and  tne  sequence  lists  ail  solutions.  Tne 
domain  and  range  specification  can  tnus  be  specified  as: 
K_QOEENS:N  ->  <LIST(N)> 

Tne  output  condition  is  derived  from  tne  problem 
constraint  structure.  It  is  simply  tne  conjunction  of  all 
constraints  in  tne  problem  representation,  formulated  in  an 
appropriate  logical  specification.  Using  X  to  represent  a 
solution  and  PATH_LIST  to  represent  tne  sequence  of  ail 
solutions  tne  output  condition  is: 

FOR  ALL  x(i),x(j)  IN  X,  X  IN  PATH_LIST 
[i*J  =>  x(i)*x(  J)  d. 
i*J  =>  abs(i-j)*abs(x(i)-x(  j)  )   S. 
1  =<  x(i)  =<  KJ 
Si  length  :X  =  £ 

The  input  condition  is  derived  from  tne  observation  tnat  tne 

program  should   produce  valid  output  regardless  of  tne  value 

of  tne  input,  as   long  as   the  input  is  of  tne  proper  type. 

Tnis   type   restriction  is  already  provided   by   tne   domain 
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designation .  Tne  input  condition  is  thus  vacuously  true  and 
reduces  the  truth  of  tne  input/output  implication  t7>  tne 
truth  of  the  output  condition.  Tne  complete  specification 
is  given  at  Figure  5. 


£_QUEENS:K  =  PATH_LIST   sucn  that 
true  =>  FOR  ALL  x(i),x(J>  IN   X, 

X  IN   PATH_LIST 
Li*j  =>  x(n*x(,n  * 
i*J  =>  at>s(i-j)#abs(x(l)-x(j))   5, 
1  <=  x(i)  <=  X  J 
*   lenstn(X)  =  K 
where  I   QOBENS:N  ->  <LIST(N)> 


FIGURE  5 
K  QUEENS  Problem  Specification 

3 •   IHH£li£n  S^eci flea t ion 

We  will  now  apply  our  reduction  rule  to  tne   formal 

K  QUEENS  problem  specification.   The  application  of  the  rule 

will   instantiate   the  specification  scnemas  for   the   lower 

level  functions  and   produce   a  Dac£trac£  schema  with  formal 

specifications   for   the    lower   level    functions.    Our 

discussion   of   the   rule  application   will   illustrate   tne 

pattern  matcning   process.    Any   reference   to   tne  proolem 

specification  witnin  tne  function  specification  scnemas  will 

cause  a  search  of  tne  problem  specification  for  tne   desired 

components.   These  components  will  tnen  se  inserted  into  tne 

instantiated   function  specification.    For  example,   tne 

GENERATE  schema  specifies  tne  ran^e  of  GENERATE   to   be   tne 

range  of  tne   problem   specification.    In  instantiating  tne 

GENERATE   specification   the   range    in   the    problem 
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specification  is  extracted  and  inserted  into  the  function 
specification.  In  tnis  manner,  all  lower  level  function 
specifications  are  produced. 

For  the  £  QUEENS    problem    tne    specification   is 

listed  in  Figure  5  and  tne  reduction  rule  s^nemas  are  listed 
in  Figure  4.  We  begin  tne  rule  application  Dy  developing  tne 
specification  of  GENERATE.  Tne  scnema  lists  tne  domain  as: 

D*  =  Y  where  Rp  =  <I> 
Since  tne  problem  specification  lists  Pp  as  <IIST(N)>,  T 
matcnes  LIST(N)  and  we  nave  Dg  =  LIST(N).  Similarly,  tne 
matcn  for  Rg  produces  <LIST(N)>  as  tne  range  for  GENERATE. 
The  schema  input  condition  is  listed  as  true,  wnicn  requires 
no  match  since  there  is  no  reference  to  tne  problem 
specification.  The  output  condion  references  the  problem 
specification  only  in  tne  conjunct: 

Opg(last(x(i  ))  ) 

where  Op<?  =  subset  of  Op  wnich  directly 
restricts  decision 

Employing  our  neuristic  for   identifying   constraints   wnicn 

directly  restrict  aecisions,  tne  constraint: 

FOR  ALL  x(i)  IN  X 

11  =<  x(i)  =<  KJ 

meets  tne  first  case   and   is   inserted   into   tne   GENERATE 

specification.   All  components  of  tne  specification  nave  now 

been  produced  and  are  included  in  Figure  5. 

Schema  instantiation  for  tne   SOLUTION   function  is 


accomplished  with  tne   same   procedure 


'he   specification 
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schema    lists    trie    domain   of    SOLUTION   as: 

Ds    =   Y   vnere   Rp   =   i 
The      problem      specification      lists    Rp      as 
allows   a    '"a  ten      oetween      Y      and      LIST(N). 


<LIST(N)>,   wnicn 
List(N^   is   tnus 


identified  as   the  domain.   The  schema  specification  lists  S 

as  the  range,  which   requires   no   match   with   tne   problem 

specification.   Tne  input  condition  also  remains  true,  since 

no  problem  reference  is  required.   Tne  output  condition  does 

reference  the  problem  specification  in: 

Os  =  Ops(TEST_PATH)  <=>  b 
wnere  Ops  =  subset  of  Op  not  included 
in  Op? 

tfe   tnus  extract   all   conjuncts   of   tne   problem   output 

condition  not  listed  in  tne  output   condition  for  GENERATE 

and  place  tne-n  in  the  output  condition  for   SOLUTION.   These 

conjuncts  are: 

FOR  ALL  x(i) ,x( j)  IN  X 

[i*j  =>  x(i)tt(j)  & 
i*j  =>  abs(i-j)*abs(x(i)-x( j) )J 
£  length:!  =  K 

The  complete   specification  for  SOLUTION  is  listed  in  Figure 

5. 

The  procedure  for  FEASIBLE  is  tne   same.  Tne   domain 

and  ran^e  schema  specifications  are  tne  same  as  for  SOLUTION 

and  produce  a  domain  of   LIST(N)   and  a  range  of  P.  The  input 

condition  remains  true.   The  output  condition  specification 

of: 
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Of  =  Opf (TEST_PATH)  <=>  b 

wnere  Opf  =  subset  of  Op  wnicn  includes  ail 

conjuncts  wnicn  relate  elements 
of  decision  and  are  not  in  Opg 

references  Op  and  forces  identification  of  tnose  constraints 

not  in  GENERATE  wnicn  address  tne  decision  elements.   From 

tne  problem  specification  tnese  are  easily  identified  as: 

FOR  ALL  x(il ,x( J)  IN  X 

Ci^J  =>  x(i)*T(j)   S, 
abs(i-j)*abs(x(i)-x( j))] 

Tne  complete  specification   for   FEASIBLE  is  given  in  Figure 

5. 

4  •  EL2.£Ii01  feneration 

To  furtner  illustrate  tne  program  syntnesis  process 
we  will  develop  programs  to  satisfy  tne  specifications  for 
tne  lower  level  functions.  Tne  development  process  will  not 
be  detailed  but  will  be  only  generally  described. 

Development  of  tne  function  GENERATE  will  be 
discussed  first.  Satisfaction  of  tnis  specification  can  ce 
accomplisned  by  a  program  wnicn  constructs  a  sequence  of 
lists.  Eacn  list  is  constructed  by  appending  one  natural 
number  to  tne  input  patn.  Tne  natural  numbers  must  fall 
between  one  and  K.  A  simple  prosrram  wnicn  accomplishes  tnis 
is  : 


GENERATE:FATH  = 

AU*X_GENERATE:<PATE,    1> 
wnere 
AUX_GENERATE:<?ATE,    C0UNTER>    = 

(ECUAL:<COUNTER,    O    ->    APPENER :<PATH ,    COUNTERS 
APPENDL: LAPPENDR:^PATH,    COUNTERS 

AUX    GENERATE:  [PATH,    ADD:<1,    COUNTER>J  ) 
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K_CU£ENS :K  = 

BACKTRACKrnil 

wnere 
BACKTRACK: PATH  = 

/APPEND 

(  <X  (lambda<TEST_PATH> 

{( SOLUTION :TEST  PATH  ->  ID :TEST_PATH ," 

FEASIBLE:TEST_PATE  ->  BACKTRACK :TEST  PATE? 

NIL)}) 
(GENERATE: PATH)  ) 

GBNERATE:PATH  =  PATH_LIST  sucn  tnat 
FEASIBLE.-PATH  =>  EOR  ALL   TEST  PATH   IN   PATH_LIST 
[lengtn(TEST_PATE)  =  l+length(PATHl  \ 
tlr(TEST_?ATH)  =  PATH    & 
1  <=  las?(TEST_PATH)  <=  K  j 

wnere   GENERATE:LIST(N )  ->  <LIST(N)> 

SOLUTION  :TEST_PATH  =  d   such  that 
b  <=>  (FEASI£LE(tlr:TEST_PATH)  => 

FOR  ALL  x(i),x(i)  IN   TEST  PATH 
ti#j  =>  x(i)*x(j)   & 
i*j  =>  aos(i-j)*abs(x(i)-x( j))J 
&   lengtn(TEST_PATH)  =  K) 

wnere   SOLUTION:LIST(  N  )  ->  B 

FEASIBLE :TEST_PATH  =  b   sucn  tnat 
b  <=>  {FEASIBLE(tlr:TEST  PATH)  => 

FOR  ALL  x(i)tx(iT  IN   TEST  PATH 
[i*j  =>  x(i)*x(j)   & 
1#J  =>  abs(i-J)*abs(x(i)-x( j))J 
where   FEAS IBLE:LIST(N )  ->  B 


FIGURE  6 
K  QUEENS  Program  Specification 

The   next  function  to  be  developed   is   FEASIBLE.  We 

wish   to   develop  SOLUTION  after   FEASIBLE  since   SOLUTION 

properly  includes  all  tne  constraints  in  FEASIBLE.  This  will 

allow   inclusion   of  FEASIBLE  witnin  SOLUTION.   FEASIBLE   is 

expressed   as   a   conjunction   of   two   constraints.    This 
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translates   into   tne   AND   of   two    computable    Boolean 

expressions.   The  first   expression   compares   tne  values  of 

all  elements  in  tne  parameter.   Tne  input  condition  tens  us 

that   all   elements   in   tlrrPATH   meet   tnis   condition. 

Therefore  we  only  need  compare  the   last   element   witn  tne 

rest  of  the  elements.   The   second  expression  compares  tne 

absolute  values  of  tne  difference  of  the  row   positions   and 

the  difference  of  the  column  positions.   Since  we  Know   tnat 

tnis  coniition  nolds  for  all  elements  of  PATH  except  for  the 

last,  we  only  need  test  tne  last  element.   This  gives  us  tne 

program: 

FSASI.BLE:?ATH    = 

AND:  [ROW_PATCE:PATH, 
DIAG_MATCH:PATH] 
where 

ROW_MATCH:PATH    = 

(NULL: PATH   ->    true; 
AND  :  [NSQUALS: [LAST:PATH,    1 :PATHJ  , 
ROW    MATCH(TL:PATH)J ) 
DIAG_*ATCH:PATH~   = 

(NULL: PATH   ->    true; 

AND: rNEQUALS[A£S(-: [TLrPATH,  1:PATHJ  ) , 

ABS(-: [LENGTH: PATH,  1J)J, 
DIAG_MATCH(TL:PATH)J  ) 

The   lerivation  of   tne   function   SOLUTION   is  now 

simple.   SOLUTION   contains   tne   conjunction   of   three 

constraints.   Two  of  tnese  are  included  in  FEASIBLE.  We   can 

include  FEASIBLE  and  tne  final  constraint  in  an  AND  function 

to  complete  tnis  program.   Tnis  gives  us: 

SOLUTIONtPATH  = 

AND:  [FEASI£LE:PATH, 

EQUALS :[£,  LENGTH  :PATHJ J 

After  derivation   of   tnese   programs   tne   syntnesis  system 
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would   replace   tne  specifications  of  Figure   6  witn   tnese 
programs  and  tne  process  would  De  complete. 

D.   THE  PROCESSOR  SEQUENCING  PROBLEM 

Tne  Processor  Sequencing  Prooiem  is  a  Known  NP  complete 
problem  (Ref.  20)  •  It  differs  from  tne  K  QUEENS  prooiem  in 
tttat  trie  patn  elements  under  examination  at  any  stage  of  tne 
process  nave  a  number  of  associated  properties  and  tne 
constraint  rela tionsnips  are  expressed  predominantly  in 
terms  of  tnese  properties,  ^he  solution  to  this  problem 
will   illustrate   tne  use   of  global  data   in   bacKtracxin* 

algcritnms   and   tne  incorporation  of  constraints   into  tne 
function  GENERATE. 

1  •   PlcJ2A°02  Eep.re.se.nia tion 

The  Processor  Sequencing  Problem  (PSP)  nay  be  simply 
stated:  Given  a  set  of  tasxs  to  be  run  on  a  single 
processor,  witn  eacti  tasn:  naving  an  associated  release  time, 
processing  time  and  deadline,  does  tnere  exist  a  scneduling 
sequence  wnicn  will  complete  all  tasics  prior  to  tneir 
deadline?  Tne  associated  properties  place  a  series  cf 
constraints  on  tne  tascs.  Tne  release  time  is  an  earliest 
possible  availability  constraint.  No  tass  is  available  to 
run  before  its  release  time.  Once  selected  for  execution, 
aacn  tasK  will  consume  exactly  tne  amount  of  time  specified. 
by  its  processing  time.  Tne  deadline  places  a  latest 
completion  constraint  on  eacn  taslc. 
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Tne  first  tasx  in  representing  tnis  problem  is  to 
iecile  on  a  iecision  structure.  One  obvious  component-  of  a 
decision  is  whicn  tas£  to  run  next.  But  tnis  is  not 
complete  in  tnat  more  information  is  required  about 
scheduling  tnis  tast  tnan  mere  selection  provides.  Tne  time 
tbe  tasK  is  scheduled  to  run  is  also  a  crucial  part  of  tne 
decision.  This  time  is  not  fixed  basea  on  tne  previous 
decisions  in  tne  partial  solution  vector,  but  depends  on 
additional  information.  For  this  reason,  the  decisions  made 
for  this  problem  can  ne  represented  by  a  pair,  tne  first 
element  being  the  tasfc  selected  and  tne  second  element  beins1 
tie  start  time  of  me  tast. 

Tne  second  representation  taste  is  to  transform  the 
decision  structure  into  a  solution  structure.  Tne  solution 
structure  will  consist  of  a  sequence  of  decisions,  eacn 
decision  being  of  tne  form  specified  by  tne  iecision 
structure.  Thus  a  solution  will  nave  the  form: 
X  -  (  x(l)t  x(2) x(N)  ) 

where  each  x(i)  is  of  form 
(  tasK(i),  timed)  ) 

The  final  representation  taste   concerns  tne   problem 

constraints.   A  number  of  constraints  relate  tne  elements  of 

the  possible  solutions.   The  first  we  will  consider   is   tne 

deadline  restriction  imposed  on   eacn  taste.   Wnether  a  taste 

meets  its  deadline  depends  on  two  factors:   tne   taste  start 

time   and   tne  taste  processing  time.   Tne  start  time   is   an 

element  of  tne   decision   being  tested.   The  processing  time 
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and  leadline  tine   are   constant  values  associated  wit.n  eacn 

instance  of  tne  problem.   A   taste  meets  its  deadline  -if  tne 

sum  of   tne   start  time  and  tne  processing  time  is  less  tnan 

tne  deadline.   Tnis  can  be  expressed  in  computable  form  as: 

FOR  ALL  i (i)  IN  X 

[deadline( tasfc( 1 ) )  >=  start(i)  +  time( tasxf i ) ) J 

wnere  deadline,  time  are  problem  constants 

Anotner  solution  element  constraint  is  identified   by  tne 

fact  tnat  no  tas&  may  be  scneduled  twice.   Tnus  eacn  tasi  in 

tne  sequence  must  be  distinct.  We  can  represent  tnis  by- 
noting  tnat  if  tne  position  of  two  tasfcs  in  tne  sequence  are 
distinct,  tnen  tne  tasfcs  must  also  be  distinct.  Tnis  can  be 
eipressed  as: 

FOR  ALL  x(i),x(  j)  IN  X 

[  i#j  =>  tasted  )*tas£(  j  )  J 

Tnere  are  also  constraints  on   tne   start  time  or  earn  tasfc. 

Tnese  limit   tne  start   time  to  a   point  after   botn   tne 

completion  time  of  tne  previous  tasK  and  tne  release  time  of 

tne  tasK  under  consideration.   It   follows   tnat   tne   start 

time  may   be   expressed   as   tne   maximum   of   tne    two 

constraints.    Assuming   a  language  function  to   select   tne 

maximum  of   two   natural   numbers,  tnis  constraint   may   be 

expressed  as: 

FOR  ALL  x(i)  IN  X 

Istart ( i )=max( release(tasx(i)), 

start(  i-1  )+process(  tas«:(  i-ll  )  ^J 

wnere  release,  process  are  problem  constants 

Tne  final  constraint   identifies   a   solution  from  potential 
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solutions  wnlcn  meet  ail  other  constraints.  If  ail  otr.er 
constraints  are  met  and  tne  number  of  elements  of  tne 
propose!  solution  eauals  tne  number  of  tasss,  tnen  we  icnow 
tnat  all  tasts  are  incluled  in  tne  sequence.  Tfcis  final 
constraint  can  be  identified  as  our  solution  constraint  and 
is  expressed  as: 
LENGTHrX  =  K 

Tne  complete  problem  representation  is  ^iven  in  Figure  7. 


DECISION  STRUCTURE 

deccision(i)  =  itn  tasJt  to  run 

start  time  of  tasx 

SOLUTION  STRUCTURE 

<X>  wnere  eacn  X  =  (x(l),  x(2),  ...  ,x(K)) 
wnere  x(i)  =  (tasK(i),  start(i)) 

CONSTRAINT  STRUCTURE 
element  constraints 

FOR  ALL  x(i)  ,x( j)  IN  X 

[  i*J  =>  tas£(i)*tasic(  j)J 
FOR  ALL  x(i)  IN  X 

f  deadline(  tas£(i  )  )  >= 

start(i)  +  process( tasK(i ) )  J 
FOR  ALL  x(i)  IN  X 

[  start(i)  =  max( release( tasted )) , 

start (i-1 )+process( tasx(i-l )) )  J 
solution  constraint 
lensrtn(X)  =  K 

wnere  release,  process,  deadline  are  problem  constants 


FIGURE  7 
PSP  Problem  Representation 

2  •   EH2^i§Ql  ?_p.eci  f  i ca  t  i on 

As  witn  tne  K  QUEENS  problem,  tne  four  components  of 

tne  PSP  formal   problem  specification  can  ce  easily  derived 

from  tne  problem  representation.   Tne  domain  for   tne   PSP 
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problem  is  trie  type  of  the  variable  input.  In  this  case, 
the  variaole  input  is  the  nunber  of  tasss,  K,  a  r/aturai 
number.  Tne  solution  structure  should  provide  us  tne 
range.   In  this  case,  a   single   solution  is  structured  as  a 

list  of  pairs  of  natural  numbers.   Tne  first  element  of  tne 

pair  is  a  tast  identifier  and  the   second  element  is  a  start 

time  for  that  tasK.   Since  tne  problem  requires   a   sequence 

of  all  solutions,  tne  proper   ranee   is  a  sequence  of  lists. 

tfe  can  express  this  as: 

PSP:N  ->  <LIST(NxN)> 

Tne  problem  output  condition  is   immediately  derived 

from  tne  constraint  structure.   It  is  merely  tne  conjunction 

of  all  constraints  we  nave   identified.   Tne  expression  of 

tnis  output  condition  is  more  complex  tnan  for   tne  K  OUEENS 

problem  because   tne   constraints   rely  on   constant  values 

defined  by  tne  problem  instance.   Our  notation  for  declaring 

these  constant  values  will  be  tne  wnere  declaration   of  cur 

programming  language.   Tnis  declaration   in  effect  defines  a 

scope  of  visibility  for  tne  constants,  making  tnem  Known   to 

the  constraints.   The  problem  output  condition  is: 

FOR  ALL  x(i)  ,x(  j)  IN  X 

Li*j  =>  tasK{i)*tas»t(J)  & 
deadiine(tasK(i ) )  >= 

start(  i  )+process  ( tast(  i  )  )   5. 
start  (i  )=max(  re  lease  (tasic(i)), 

start (i-1 )+process( tasK(i-l)  )  )J 
\   lenetn:X=K 

wnere  release,  process,  deadline  are  program  constants 
For  reasons  tne  same  as  witn  tne   K  QUEENS  problem  tne  input 
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condition    is   vacuously   true.        Tne   complete   specification   is 
given    in    Figure  8. 


PSP:K   =    TASK_LIST      sucn    mat 

true      =>    FOR  ALL   x(i),x(j)    IN    X,    X    IN    TASK_LIST  , 

and  x(i)    =    ( tasic(  i  ) ,  start(  i  )) 
[i/j    =>    tasfc(i)*tasi(J)      & 
deadline( tasK( i )    >= 

start (i )+process( tasK(i ) )      £ 
start(i)    =  max( released tasK( i )) , 

start  (i-i  )+process(tasit(i-l  )) )    J 
&  lengtn(X)    =  S 

vnere  PSP:N  ->  <LIST(NxN)> 

and  release,  process,  deadline  are  problem  inputs 


FIGURE  8 
PSP  Problem  Secification 

3-   Function,  Specification 

tfe  now   apply   our   reduction   rule   to   produce  a 

bacJctracJ*  program  witn  formal  specifications  for  tne   lower 

level  functions  wnicn  will  solve  tne  PSP  problem.   To  co  so 

we  use   tne   scnemas   of   Figure  4  and  tne  formal   problem 

specification  of  Figure   S.   Ve  be^in  with  tne  specification 

of  tne  function  GENERATE.  Tne  specification  scnerca  lists  tne 

domain  as  7,   wnere  Rp  =  <Y>.   Matcainsr  tnis  against  tne 

problem  specification  provides  Rp  as  ^LIST(NxN)>  wnicn  gives 

Y  as   LIST(NxN).   Tnis   is  placed  as  tne  domain  of  GENERATE. 

Tne  scnema  lists  tne  range  as  Rp  so  we  nave: 

GENERATE:LIST(NxN)  ->  <LIST(NxN)> 

Tne  scnema  input  condition   does   not   reference  tne  problem 

specification   so   it    is   copied   into   tne   GENERATE 

specification.   In  a  iiie  manner  tne  first  two  conjuncts   of 
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tne  scnema  output  condition  are   copied   into   t&e   SilNSRATE 

specification.    Tne   final   conjunct   references   Ops-,   tne 

subset   of   tne   problem  output   conditions   w.ni^n   directly 

restricts   a   decision  element.    Examining   tne   problem 

specification  under  tne  guidance  of  our  neuristic  produces  a 

matcn  with  the  conjunct: 

FOR  ALL  x(l)  IN  X,  X  IN  TASK_LIST 

and  x(i)  =  (tasi(i),  start(i)) 
[start(i)  =  max  ( release  ( tasic(i) , 

start (i-1 )+process ( tastcf i-1 )) )  J 

and  case  two  of  tne  rule.  Case  two  prescribes  tne  inclusion 
of  problem  constraints  wnich  in  the  GENERATE  function  if  a 
constraint  restricts  a  single  decision  element  by  an 
equality.  In  this  case  start(i)  is  the  decision  element  and 
it  is  restricted  by  an  equality.  Case  one  produces  no  matcn 
since  no  constraint  bounds  a  decision  element  by  constant 
values.  Tne  schema  entry  for  Opg  is  replaced  by  the 
conjunct  above  producing  the  full  specification  of  Figure  9. 
Tne  same  procedure  is  used  to  develop  tne  formal 
specification  for  SOLUTION.  Tne  scnema  specifies  tne  domain 
as  Y  wnere  tne  problem  range  is  <T> .  The  problem  range  is 
<LIST(NxN)>,  wnicn  produces  a  Y  match  of  LIST(NxN),  wnicn  we 
taice  as  tne  domain  of  SOLUTION.  Tne  scnema  range  does  not 
reference  the  problem  specification,  so  it  is  copied  into 
the  function  specification.  Tne  same  is  done  for  the 
function  input  condition.  Tne  scnema  output  condition 
references  Ops,  the  subset  of  the  problem  output  condition 
•mien   is   not  included  in  Opg.  From  tne  discussion   in   the 
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last  paragrapa  tnis  reduces  to  tne  first,  second  and  fourtii 
conjuncts  in  tne  problem  output  condition.  Replaci-ne-  Ops 
witn  tnese  conjuncts  produces  tne  specification  of  Figure  3. 
Tne  specification  for  SOLUTION  is  ider.tical  to 
FEASIBLE,  as  snown  in  tne  scnemas,  witn  tne  exception  of  tne 
output  condition.  In  tnis  case,  tne  reference  to  Opt  in  tne 
scnena  must  be  replaced  by  all  conjuncts  of  tne  prcolem 
output  condition  wnicn  relate  decision  elements  and  are  not 
in  Op*.  Witn  tnis  problem  tne  last  conjunct  does  not  relate 
decision  elements  since  it  addresses  tne  solution  as  a 
wnole.  Tne  tnird  construct  is  included  in  Op^.  Tnis  leaves 
tne  first  two  constraints  to  De  substituted  for  Opf .  Placing 
tnese  constraints  into  tne  scnema  produces  tne  specification 
of  Figure  3. 

E.   SCHEMA  LIMITATIONS 

Tne  reduction  rule  developed  in  tnis  cnapter  nas  a 
number  of  limitations.  Tne  principal  deficiency  is  tnat  it 
is  neuri5tic  in  nature  and  not  an  algorithm.  Tne  underlying 
reason  for  tnis  is  tne  failure  of  tne  rule  to  incorporate 
any  proof  mecnanism  in  its  actions.  It  is  believed  tnat  a 
proof  mecnanism  may  be  constructed  based  on  tne  design 
metnod  developed  above.  Reduction  rules  for  tne  simple 
divide  and  conquer  control  strategy  nave  teen  developed  by 
Smitn  [Ref.  Hi  J  wnicn  employ  a  proven  tneorem  as  tne  basis 
for  specification  development. 
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PSP:K   = 

BACKTRACK  mil 

wnere 

BACKTRACK  .-PATH    = 
/APPEND 

(*  (lambda<T£ST    PATH> 

{(SOLUTION:  TEST   PATH   ->   ID:TEST_PATH  ; 

FEASIBLE:TEST_PATH    ->    BACKTRACK :TEST  PATH! 

NIL)}) 
(GENERATE:PATH)     ) 

GENERATErPATH   =    PATH_LIST      such    that 
FSASIBLErPATH    =>    FOR   ALL    x(i),x(j)    IN    X, 

X      IN      PATH_LIST 
and    x(i)    =    ( tasfc( i ) , start f i ) ) 
[lengtn(X)    =   1+lengtn  (PATH)      & 
tlr(X)    =   PATH        b, 
start(i)    =   rrax  (release(  tas£(  i  ) ) , 

start ( i-1 )+process( tasK( i-l) ) ) J 

where      GENERATE:LIST(NxN )    ->   <LIST(NxN)> 

SOLUTION :TEST_?ATfi   =    b      such    that 
b    <=>    (FEASIBL£(tlr:TEST_PATH)    => 

FOR    ALL    x(i)7x(j)    IN      TEST    PATH 

where   x(i)    =    (tassTi),    start(il) 
[i#j    =>   tasir(i)*tasK(  j)      S, 
deaaline{  tasJt(  1)  )    >  = 

start(i)+orocess(taSK(i )  J 
4      lengtn(TEST_PATH)    =   K} 

where   SOLUTION :LIST( NxN )    ->   B 

FEASIBLE:TEST_PATH    =    b      such    that 
b    <=>    {FEASI3LE(tlr:TSST    PATH    => 

FOR    ALL    x(i)7x(jl    IN      TEST_PATH 

wnere   x(i)   =    (tasjc(i),    start  (i)) 
[i*J    =>    tasx(i)*tass( j)      & 
deadline(  tasK(i)  )    >= 

start  (  i  )+process(  taslrd  )  )  J } 

where    FEASIBLE: LIST( NxN )    ->   B 

where   release,    deadline,    process    are    program    constants 


FIGURE    9 
PSP   Program   Specification 


A  second  limitation  of  tne  rule  Is  tne  lref f ici°r.cy 
inherent  in  tne  oacxtracK  scnema.  As  evidenced  by  our 
examples  tnere  is  mucn  lupllcate  computation  between  tne 
SOLUTION  ana  FEASIBLE  predicates.  Tnls  couid  indicate  tr.at 
efficiency  is  better  served  oy  evaluating  tne  FEASIBLE 
predicate  first  and  tnen  nesting  a  dimimsned  form  of  tne 
SOLUTION  predicate  witnin  tne  action  clause  of  FEASIBLE. 
Altnougn  our  design  metnod  would  allow  tnis,  it  restricts 
tne  scnema  to  prooiems  wnere  tne  FEASIBLE  constraint 
Includes  only  restrictions  witnin  SOLUTION  as  well.  It  is 
not  Known  wnetner  tnis  is  a  general  condition  wi tn  problems 
suitable  for  tne  bacstracK  solution  tecnnique  and  tne  mere 
eeneral  senega  of  Figure  3  was  developed  instead. 

A  general  efficiency  concern  in  tne  development  of  any 
bacitracfc  al^oritnm  is  tne  proper  subdivision  of  constraints 
between  GENERATE  and  tne  otner  functions.  Obviously,  any 
constraint  witnin  GENERATE  filters  nonfeasiele  partial 
solutions  from  SOLUTION  and  FEASIELE.  How  mucn  total 
computation  is  saved  is  not  clear,  nowever.  Tne  total 
number  of  nodes  examined  by  tne  predicates  is  less  wnen  more 
of  tne  constraints  are  included  witnin  GENERATE,  but  tne 
computation  required  by  GENERATE  is  greater.  A  general 
conclusion  tnat  seems  valid  is  tna  t  some  work:  is  saved  if 
tnere  is  also  duplicate  computation,  as  discussed  above, 
between  SOLUTION  and  FEASIBLE,  but  if  tnere  is  no  duplicate 
computation,  tnen  eacn  extension   at   eacn   level  visited  is 
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teste!  once  against  eacfi  constraint.  A  more  favoraole  area 
for  related  investigation  is  in  program  transformation. 
Tnis  wont  may  identify  wnen  bacictracK  programs  produce 
iuplicate      computation,      and      transform      sucn      programs        to 

eliminate   tne    duplication. 
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7.  AN  EXTENSION  TO  BACKTRACK 

Tile  bacKtracK  algoritnm  nas  traditionally  been  employed 
to  solve  problems  of  tne  type  described  in  Cnapter  III. 
Researcn  on  tne  strategy  has  been  oriented  towards 
efficiency  improving  techniques,  [Ref.  22,  23J  program 
proving  [Ref.  24 J  ,  problem  representation  formalisms  [Ref. 
25J  and  control  structure  abstraction  [Ref.  2b,  27J .  Tne 
problem  of  extending  tne  strategy  for  solution  of  a 
different  class  of  problems  nas  not  been  significantly 
addressed.  Tne  second  reduction  rule  proposed  cy  tnis  paper 
extends  tne  tactctractc  strategy  by  adapting  it  for  solution 
of  tne  problem  reduction  problem  type.  Tne  result  is  a 
general  purpose  scnema  witn  a  neuristic  design  metnod  for 
lower  level  function  specification.  As  tnis  result  is  less 
rooted  in  existing  Knowledge,  tne  design  metnod  presented 
will  be  described  in  general  terms. 

A.   PROBLEM  REDUCTION  PROBLEM  REPRESENTATION 

A  problem  reduction  problem  representation  is  another 
formalism  for  symbolic  problem  description.  As  witn  tne 
state  space  representation  discussed  in  Cnapter  III, 
representation  of  a  problem  witn  a  problem  reduction  format 
will  impose  a  particular  grapnic  structure  onto  tne 
problem,  rfitn  tnis  structure  we  can  employ  a  grapn  sear~n 
procedure  to  searcn   fcr   a   solution.    Tne  goal   in   tnis 
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cnapter  is  to  adapt  trie  bacKtracx  strategy  to  searcfl  tne 
problem  reduction  grape.  In  tnis  paragraph  we  win-first 
develop  tne  representation,  tnen  depict  tne  grapn  structure 
produced  by  tne  representation,  and  tften  illustrate  a  sarple 
problem   representation. 

1  •      P£OJil£!2  E§EI!£sen£atl  on 

Tnere  are  tnree  trey  components  of  a  problem 
reduction  representation.  Tne  first  component  is  tne 
problem  state.  Tnis  is  a  symbolic  description  of  tne  state 
of  tne  problem  at  any  point  in  tne  searcn  process.  Tne 
initial  problem  state  is  a  description  of  a  ?oal  wnicn  is  to 
be  satisfied.  As  tne  searcn  process  executes,  tne  initial 
goal  state  will  be  decomposed  into  one  cr  more  sub^oai 
states,  wnicn,  wnen  botn  are  satisfied,  will  cause  tne 
original  goal  to  be  satisfied.  An  example  of  tnis  is  tne 
symbolic  integration  process.  Given  a  goal  state  of  tne 
f  orm : 

f(tix)    *  g(x))  dX 

wnere  f,?  are  Known  functions 

A  solution  to  tnis  problem  is  a  symbolic   representation   of 

tne  integral.    An  initial  decomposition  may  produce  tne  two 

subgoals : 

/f(x)  dx 
/g(x)  dx 
wnere  f,g  are  Known  functions 

Solving1  botn  of  tnese  two  subsoais  will  lead  to  tne  solution 
of  tne  original  problem.   In  tnis  case,  tne  two  sucsolutions 

must  be  added. 
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In  order  to  decompose  states  and  compose  solutions 
some  means  must  be  provided  for  tnese  actions.  T*e  second 
component  of  a  problem  reduction  representation  is  a  set  of 
reduction  rules.  £acn  rule  will  act  on  a  goal  description 
and  provide  one  or  more  decomposed  subgoals.  Tne  rule  also 
provides  a  metnod  for  combining  solutions  to  subgoals  into 
solutions  to  tne  original  goal.  Tne  most  significant  aspect 
of  rule  application  is  tnat  all  subgoals  must  te  solved  for 
tne  original  goal  to  be  solved.  In  our  symbolic  integration 
example  tne  reduction  rule  applied  may  be  of  tne  fern: 

If  Integrand  is  form  f(x)  +  g(x) 

wnere  x  is  variable  of  integration 
tnen 

solve  f(x)  ana  g(x) 

compose  solutions  with  + 

It  is  important  to  note   tnat   tnere  is   an  applicability 

condition  (If)  and  a  conjunctive  solution. 

Tne  representation  we  nave  described  tnus  far  allows 

only  goal  decomposition.   Tne   tnird  component   of   tne 

representation  allows  for  a  solution  of  a  subset  of  goals  we 

will  call  primitive.   Tnis  component  is  a  set  of  rules,  also 

called  primitive,  wnicn,  when  applied   to  a  primitive  goal 

will   return   a   solution.    In   our   symbolic   integration 

example,  one  primitive  rule  may  be: 

If  Integrand  is  of  form  cos  x 

wnere  x  is  variable  of  integration 
then  return  sin  x 

The  primitive  operators  provide  tne  only  means  of  finding  a 

solution  in   a  problem  reduction  representation.   Tney  are  a 
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means  to  represent  tnose  goals  wmcn  we  *now  now  to  directly 
solve. 

2»  kU'l/.Q.L  ll^e   l£B£°S.eniat.ion 

The  grapn  structure  imposed  by   this   representation 

is  similar  to  the  structure  of  a  state  space  tree,  but 
contains  an  additional  node  type.  We  will  represent  eroal 
descriptions  by  nodes  ana  rule  applications  by  arcs.  Tne 
path  from  tne  root  of  a  tree  to  a  subgoal  description 
describes  the  sequence  of  rule  applications  wnicn  produced 
tne  ffoal  description.  Given  a  node  (goal  description'  tnere 
is  a  ranee  of  reduction  rules  which  may  be  applied.  This 
range  is  represented  by  the  set  of  arcs  leaving  the  node. 
The  complicating  factor  of  the  problem  reduction 
representation  lies  in  reduction  rules  wnicn  decompose  a 
goal  description  into  two  or  more  suogcals.  The 
reiationsnip  between  tnese  subgoals  is  tightly  constrained, 
representing  tne  fact  that  botn  of  tnese  suogoais  must  be 
solved  to  solve  tne  eoai.  This  logical  and  relationship 
contrasts  with  tne  subgoals  produced  by  tne  otner  reduction 
rules.  Satisfaction  of  tne  subgoals  produced  by  any 
reduction  rule  will  satisfy  tne  goal.  Tne  .errapnic  solution 
is  to  tie  together  tne  arcs  representing  application  of  one 
rule  with  a  nyperarc.  Tnis  creates  an  AND  node,  wnicn 
signifies  that  all  descendants  of  the  AND  node  must  be 
satisfied.  The  application  of  distinct  rules  are 
represented  by  OR  nodes,  or  arcs  not  connected  by  nyperarcs, 
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wnicn  represent  tne  logical  OR  nature  of  tneir 
relationship.  Figure  lid  depicts  a  sample  searcn  space. 
Given  an  initial  goal  represented  as  node  A,  tnree  reduction 
rules  can  be  applied.  Rule  1  produces  subgoals  B  ana  C, 
rule  2  produces  sub?oal  D  and  rule  3  produces  sub^oais  E  and 
F.  A  can  be  solved  by  solving  eitner  set  of  goals,  it  and  C, 
or  D,  or  S  and  F.  Ultimately,  if  B  and  C  are  to  be  solved 
tben  G  or  H,  and  I  must  be  solved.  If  D  is  to  ce  solved, 
tnen  J  and  K  nust  be  solved.  If  E  and  F  are  to  ce  solved, 
tben  L  and  M  and  N  must  be  solved.  To  solve  tnis  problem 
tne  searcn  process  must  searcn  for  subeoals  wfticn  can  be 
solved  by  primitive  operators  and  tie  to^etner  tne  separate 
patas  represented  by  and  nodes.  Uniise  tne  state  space 
searcn,  tne  result  of  tnis  searcn  process  will  be  a  solution 
tree.  From  any  node  tne  separate  brancnes  represent  tne 
different  subgoals  produced  by  a  single  rule  application. 
As  an  example,  Figure  11  depicts  tne  four  solution  trees 
present  in  Figure  I'd   if  all  leaf  nodes  can  be  solved. 

Tne  examole  we  present  nere  and  develop  for  tne 
remainder  of  tne  cnapter  is  a  simple  aritnmetic  tneorem 
prover.  Given  a  goal  statement  in  terms  of  a^  aritnmetic 
assertion  in  any  number  of  variables,  and  a  number  of 
propositions  about  tnose  variables  we  Know  to  be  true,  can 
we  prove  tne  statement  is  true.  In  tnis  para^rapn  we  will 
develop  a  problem  reduction   representation  for  tne  problem, 
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an!  in  later  paragraphs  we  will  adapt  tne  DacKtrarK  control 
strategy  to  searcn  tne  representation  defined  A.ND/OP.  tree 
and  return  a  proof  of  tne  assertion. 


FIGURE  Id 
AND/OR  Grapn 


FIGUR3  11 
Solution  Grapfts 

To  represent  our  problem  witn  a   problem  reduction 

formalism  we  need  to  define   tne   tnree  components   of  tne 

representation.    Tne   first   component   is    tne   ^oal 

description.   Tne  initial  goal  is  an  aritnmetic   assertion. 
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I  suitable  goal  description  is  trie  assertion  itself.  Tne 
result  of  applying  a  reduction  rule  will  be  one  or.  more 
suD?oals,  eacn  of  wnicn  snould  be  a  simpler  aritnmetic 
assertion.   For  our  problem   representation  we  can  express 

tnis  as: 

GOAL  DESCRIPTION 

form:  aritnmetic  assertion 
initial:  [B  *  (A  +  C ) J /E  >  B 

The      initial   ?oai   description   represents   tne   particular 

problem  instance  to  solve. 

Tne  next  component  we  describe   is   tne   set  of 

primitive  rules.   Tnese  rules  need   to   be  described  before 

tne  reduction  rules   because  tney  provide  tne  basis  towards 

wnicft   tne   reduction  rules   snould   simplify  tne   goal. 

Primitive  rules  represent  tne  Knowledge  possessed  about  tne 

problem.   Tney  specifically  apply   to  ?oal  descriptions  tnat 

can  be  directly  solved.   In  tne  tneorem  prover,  tnese   rules 

are  expressions  of  tne  propositions  wnicn  are  Known   to   be 

true.   For  tne  problem  instance  we  are  concerned  witn   tnese 

are : 

PRIMITIVE  RULES 
A  >  0 
B  >  0 
C  >  0 
E  >  id 
C  >  E 

To  complete  our  problem  representation  we  need  only 

specify  tne  reduction  rules.   Tne   purpose   of   a   reduction 

rule  is   to   simplify   a  £oal  state  wnicn  cannot  be  directly 

solved  by  a  primitive  rule.   It  follows  tnat  reduction  rules 
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embody  general  Knowledge  about  problem  area  relationships 
wnicn  allow  transformation  of  goal  descriptions  into  one  or 
more  simpler  descriptions.  In  simple  tneorem  proving  tnese 
rela tionsnips  can  be  described   witn  logical   implications 

wnicn  represent  eeneral  Known  theorems.  Tney  can  be  stated 
in  the  form: 

PI  &  P2  5,  ...  6,  PK  ->  PK 

wnere  P0  represents   a  ?oal  and  PI,   ...   ,PK  represent 

subgoals.   If  P0  can  be  matcned  against  a  goal   description, 

tnen  subgoai  PI   ...  PS  will  be  produced,   We  will  use  four 

reduction  operators  for  tne  tneorem  prover: 

REDUCTION  OPERATORS 
x>0  5.  y>0  =>  x*y  >  0 
x>0  6,  y>z  =>  x+y  >  z 
x>0  5,  y>z  =>  x^y  >  x*z 
x>z*y  i-  y>0  =>  x/y  >  z 

Tne  complete  problem  representation  is  given  in  Figure  12. 


GOAL  DESCRIPTION 

form:  aritnmetic  expression 
initial:  [3  *  (A  +  C)J  /  E  >  B 

PRIMITIVE  RULES 

A  >  0         B  >  0 

C  >  0         E  >  0 
C  >  £ 

REDUCTION  RULES 

x>0  5,  y>0  =>  x*y  >  0 
x>0  &  y>z  =>  x+y  >  z 
x>0  £  y>z  =>  x'y  >  x*z 
x  >  z*y  5,  y>0  =>  x/y  >  z 
i 

FIGURE  12 
Tneorem  Prover  Problem  Representation 
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B.   SCHEMA  DEVELOPMENT 

In  developing  the  bacstracK  sctema  for  a  problem 
reduction  representation  tne  procedure  described  in  Cnapter 
IV  will  again  be  followed.  Tnis  procedure  requires 
description  of  tne  expected  input,  description  of  tne 
desired  output,  identification  of  tne  operations  required  to 
transform  tne  input  to  the  output  and  tnen  translation  of 
ttie  operations  into  lower  level  functions  and  appropriate 
functional  forms. 

1  •   I_H§.  Exp_ec ted  I np,u t 

A.s  in  tne  state  space  bacstracx  scnema  a 
representation  of  a  patn  is  expected  as  input.  Tnis  patn  is 
a  symbolic  description  of  tne  sequence  of  rule  applications 
wnicn  nave  reduced  tne  initial  goal  description  to  tne 
current  ?oal  description.  Since  tne  patn  does  not  include 
tne  current  ?oai  description,  tnis  must  also  be  included  in 
tne  expected  input.  Tne  resulting  input  is  a  sequence 
consisting  of  a  patn  and  a  symbolic  representation  of  tne 
current  goal. 

Tne  relevant  cnaracteris tics  of  tne  input  are  two. 
Tne  first  is  tnat  all  rules  in  tne  patn  dave  been 
successfully  applied.  Tne  second  is  tnat  tnis  current  goal 
may  be  primitive.  Tnis  situation  is  a  result  of  tne 
bacKtracfc  strategy  applying  tne  SOLUTION  predicate  before 
tne  FEASIBLE  predicate.  Tnis  will  be  furtner  discussed  in 
tne  section  on  input  transformations. 
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2»   5^slr°i.  Output 

The  output  desired  from  a  problem  reduction 
representation  is  often  dependent  on  the  problem.  For 
example,   the  desired  output  for  tfte   symbolic   integration 

problem  is  a  symbolic  description  of  tne  integral.  With  the 
simple  tneorem  prover  we  desire  proof  of  the  input 
assertion.  A  commonality  between  tnese  ana  ail  problem 
reduction  representations  is  tne  sequence  of  operations 
performed  to  arrive  at  a  solution.  For  tnis  reason  the 
general  output  desired  will  be  a  solution  grapn  consisting 
of  the  reduction  rules  and  primitive  rules  applied  to  solve 
tne  problem.  The  return  from  tnis  most  general  case  can  be 
transformed  into  tne  desired  output  form. 
3 .   Input  Transformations 

In  describing  tne  input  transformations  required  we 
will  stay  as  cio^e  as  possible  to  the  simple  ba^mracK 
scnema  developed  in  Chapter  IV.  The  goal  is  to  produce  a 
schema  whicn  can  be  applied  to  either  tne  state  space 
representation  or  tne  problem  reduction  representation.  Tne 
iesis-n  method  will  differ  based  on  tne  problem 
representation.  To  do  so  we  will  identify  tnose  aspects  of 
the  simple  bacKtracK  schema  which  require  enhancement  to 
search  an  &ND/OR  graph,  and  develop  those  enhancements  in 
either  tne  scnema  or  the  design  metnod. 

Tne  initial  transformation  required  is  to  extend  tne 
path  parameter.   In  this  case,   the   extension   consists   of 
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appending  one  more  reduction  rule  to  tne  patn  of  rules 
previously  applied.  Tnis  extension  does  not  apply  tfie'ruie, 
but  lists  it  as  one  possible  alternative.  Tne  result  of 
ttiis  transformation  will  be  a  new  sequence   of   patn,   state 

pairs.  Eacn  pair  represents  a  different  alternative 
extension  to  tne  patn  of  applied  rules. 

Tne  second  transformation  is  tne  conditional  test. 
Tne  SOLUTION  predicate  will  again  be  executed  first.  In  a 
problem  reduction  representation  a  solution  is  not 
recognized  by  examining  tne  sequence  of  decisions  (rule 
applications),  but  oy  examining  tne  current  *oal 
description.  Upon  recognition  of  a  solution,  tne  action  is 
to  return  tne  sequence  of  rules,  and  not  tne  goal 
description.  If  tne  SOLUTION  predicate  fails  tnen  tne 
FEASIBLE  predicate  will  De  executed.  Tnis  predicate  is  a 
test  of  tne  patn  to  determine  if  a  solution  can  feasibly  be 
discovered  tnrougn  expansion  of  tne  patn.  Tne  clearest  way 
to  test  tnis  in  a  problem  reduction  representation  is  to 
test  tne  reduction  rule  appended  by  tne  patn  expansion 
transformation.  If  tnis  rule  can  be  applied  to  tne  goal, 
tnen  further  sub^oals  can  be  produced  wnicn  may  lead  to 
solutions.  If  tne  rule  can  be  anplied  tnen  tne  appropriate 
actions  are  more  complex  tnan  tnose  in  tne  state  space 
scnema.  Tne  obvious  first  action  is  to  apply  tne  rule  and 
produce  new  subgoals.  If  only  one  subgoal  is  produced  we 
nave  created  an  OP   node.    In   tnis   case   tne  appropriate 
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action  is  to  recursively  call  tne  bacictracfc  function  witr: 
tfte  new  suoeoai  and  patn.  If  more  tnan  one  sub^oai  is 
produced  an  AND  node  nas  been  created  and  more  complex 
action  is  required.  If  an  AND  node  is  created  tnen  a 
separate  patn  is  created  for  eacn  descendant  of  tne  node. 
To  solve  tne  AND  node  eacn  patn  must  return  a  solution.  To 
solve  tnis  problem  by  a  bacKtracs  searcn  we  must  searcn  eacn 
patn  and  compose  tne  solutions.  If  any  patn  returns  nil, 
the  result  of  tne  node  will  be  nil.  Tne  order  of 
transformations  on  AND  node  is  thus  to  apply  tne  rule, 
create  separate  <PATH,  G0AL>  pairs  for  eacn  sub^oal, 
backtrace  on  eacn  pair  and  finally  compose  solutions. 

The   final   transformation   is   to   filter   the   nil 
solutions  returned  by   tne   examinations   of  the  expansions. 
Tne  value  returned  will  consist  of  a  list  of  solutions. 
4*   Schema  Translation 

To  derive  a  senega  from  tne  required  transformations 
we  will  again  group  the  transformations  into  lower  level 
functions  combined  with  the  appropriate  functional  forms. 
The  first  transformation  is  tne  generation  of  expanded. 
paths.  Tnis  transformation  can  a^ain  be  accomplished  by  a 
single  function  GENERATE.  In  o^r  language  notation  tnis  is: 

GENERATE:<PATH,  GOAL> 
*nere  tne  parameter  PATH  is  a  representation  of  tne  sequence 

of  rules  applied,  and  tne  parameter  GOAL  is  a  description  of 
tne  current  2*oal. 
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Tne  second  transf orna tion  is  tne  conditional  testing 
function.  As  witn  tne  state  space  representation,  tttis 
function  is  applied  to  one  element  of  tne  output  of  GENEPATE 
and  tfte  results  are  returned  before  it  is  applied  to  tne 
next  element.   This  APPLY-TO-ALL  operation  is: 

OCTEST  (GENERATE:<PATH,  G0AL> ) 
We  can   expand   tne   function  TEST  since  we  Know  tne  actions 
required  of  it.   The  first   predicate   tests   tne  goal   for 
being  primitive.   If  it  is,  the   action   is   to   return   tne 
path.   This  can  be  expressed  as: 

SOLUTION  :G0AL  ->  IJ):PATH; 
The  second   predicate  is   a   test   for  feasibility  of 
expansion.   The  correspondine  action   is  to  apply  the  rule, 
decompose   the   pata,   subgoals   pair   into   separate   path, 
subgoal   pairs,   apply  back:trac£  to  eacn   pair  and   finally 

compose  the  results.   This  can  be  expressed  as: 

FEASIELE:<PATH,  GOAL>  -> 

COMPOSE (  BACKTRACK (DECCMPOSE:<?ATH,  GOAL>)); 

(Jsing  tne  lambda  definition  of  our  language  we  now  nave: 

(lambda  <PATH> 

{(S0LUTION:GOAL  ->  ID:PATH; 
FEASIBLE:  <PATH,  GOAL>  -> 

COMPOSE(  BACKTRAC£(EECOMPOSE:<PATH,  GOAL>  ) )  J 
NIL)}) 

(GENERATE:<PATH,  GOAL)) 

The  final  transformation  filters  the  nil  values 
returned  by  the  process.  This  can  be  expressed  as  inserting 
the  APPEND  function  throueh  the  list  of  solutions  returned. 
The  co-npiete  schema  is  eiven  in  Figure  13. 
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BACKTRACK :<PATH,    GOAL>    = 
/APPEND 
(  (X  (larrDda<PATH> 

{(SOLUTIONrGCAL    ->    ID:PATH; 
FEASIBLE:<PATH,GOAL>    -> 

COMPOSE(    BACtCTRACX(DECOMpOSS:<PATH/JOAL)  )  )', 

NIL)}) 
(GENERATE:<PATH,GOAL>)     ) 


FIGURE    13 
ijacKtract   Program   Scnerra 


C.   SUBSCHEMA  SPECIFICATION 

Tne  scnema   develooed   above   provides   a   structure  for 

composing  tne  solutions  to  trie  subprodems  GENERATE, 
SOLUTION,  FEASIBLE1,  DECOMPOSE  and  COMPOSE.  A  design  netnod 
for  specifying  tnese  subpnbiems  is  also  required.  Tnis 
paragraph  discusses  tne  relationships  between  tne  functions 
trie  schema  requires  to  solve  a  problem.  A  detailed  design 
metnod  similar  to  trie  metnod  presented  in  Cnapter  17  is  not 
developed,  but  left  for  furtner  research. 
1.   GENERATE  Specification 

Tr.e  function  GENERATE  must  accept  an  input  pair 
wnich  represents  tne  patn  of  reduction  rules  applied  and  tne 
current  goal  specification.  The  output  must  be  a  sequence 
of  pairs.  Eacn  pair  contains  a  new  patn  representation  and 
tne  goal  specification.   The  new  patn   is  tne  input  patn  to 

which  one  reduction  rule  of  those  available  to  apply  has 
been  appended.  Tne  sequence  contains  a  separate  pair  for 
2ach  available  rule.   As  an  example,  if  GENERATE   is   given 
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t tie  input: 

<(R1,  R3,  R2),  GOAL> 

and   there   are  four  reduction  rules   R1...R4  availacie   to 

apply  then  GENERATE  must  output: 

«(R1,  R3,  R2,  Rl),  GOAL>, 

<(R1,  R3,  R2,  R2),  GOAL>, 

<(R1,  R3,  R2,  R3),  G04L>, 

<(R1,  R3f  R2f  R4)f  GOAL>> 

Tnis  output  represents  ail  possible  expansions  of  tne  rule 

application  patn.   It  does  not  represent  an  expansions  witfl 

applicable  rules.   A  different   function  of  tne  scnema  will 

delete  nonapplica Die  rules. 

2.   SOLUTION  Specification 

Tne  function  SOLUTION  will  again  be  tne   easiest   to 

describe.    Tne   intent   of   SOLUTION   is   to   test   a   goal 

description  to  see  if  it  is  a   solution.    In   tne  prooiem 

reduction  representation   tilers  is  one  operation  to  test  for 

a  solution.   If  tne  goal  description   can   be   solved   by  a 

primitive   rule   tnen   a   solution   Has   been   found.    Tne 

specification  of  SOLUTION  must   express   tnis   relationship 

between  tne  ?oal  and  tne   primitive   rules.   Tne  form  of  tne 

relationship  may  differ  from   problem   to   problem.    For 

example,    in   tne   symbolic   integration   problem   tne 

relationship  is  an  application.   If  a  primitive  rvle  can   be 

applied  to  tne  ?oal ,  tnen  it  can   be  solved.   In  tne  theorem 

proving  problem  tne  relationship  is  membership.   If  tne  goal 

is  a  member  of  tne  primitive  rules  tnen  tne  goal  is  solved. 
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3-   FEASIBLE  Specification 

Tn»  function  of  tne  predicate  FEASIBLE  is  to  test  a 
path  for  tne  possibility  it  pay  leal  to  a  solution.  Tne 
patn  under  consideration  exhibits  two  cnararterist irs .    Tne 

last  element  of  the  path  is  a  reduction  rule  whicr  has  not 
been  applied  to  tne  goal  description.  Tne  remainder  of  tne 
patn  is  a  sequence  of  reduction  rules  which  nave  ceen 
applied  to  tne  initial  goal  description  to  produce  tne 
current  description.  If  the  Datn  under  consideration  is  to 
be  considered  feasible,  then  tne  last  rule  of  tne  patn  must 
be  applicable  to  tne  goal  description.  In  more  concrete 
terms,  a  reduction  rule  applies  to  a  ^oai  if  tne  rule 
produces  one  or  more  subgoals  from  tne  goal.  Tne  FEASIBLE 
predicate  must  test  this  relationship  between  tne  £-oai  and 
the  reduction  rule.  It  is  significant  that  tne  FEASIBLE 
function  does  not  actually  apply  the  rule  to  produce 
sub^oals.  It  need  only  ensure  tne  rule  can  oe  applied. 
4.   DECOMPOSE  Specification 

If  tne  patn  is  feasible  (tne  rule  can  be  applied), 
tne  next  step  is  to  produce  a  <PATH,  G0*L>  pair.  Tnis  pair 
will  De  tne  input  to  tne  recursive  call  to  .BACKTRACK.  In 
many  instances  tne  application  of  a  reduction  rule  will 
produce  more  than  one  subgoal.  For  tnis  reason  tne  function 
DECOMPOSE  must  do  more  than  apply  tne  rule  to  orepare  input 
for  BACKTRACK .  For  every  subgoal  produced  oy  tne  rule 
application,   DECOMPOSE  must  construct  a  <?ATH,  GCAL>   pair. 
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Tne  patfc  in  all  pairs  is  identical:  trie  sequence  or  rule 
applications  wnicn  produce!  tne  associated  -  ^oai 
description.  Tne  goal  description  in  eacn  pair  is  unique: 
it  describes  one  of  tne  sub^oais  produced  by  tne  rule 
application.  Tnere  are  two  important  cnaracterist ics  of  tne 
output  of  tnis  function.  If  tne  rule  application  produces 
only  one  subgoal,  tnen  tnere  is  only  one  <PATH,  GOAL>  pair 
produced,  and  tne  APPLi-TO-ALL  functional  form  of  tne  s^nema 
reduces  to  a  straight  application  of  BACKTRACK  to  tne  pair. 
Tnis  operation  is  similar  to  tne  state  spare  bacKtrac* 
scnema.  Secondly,  DECOMPOSE  has  transformed  a  <PATH,  GOAL> 
pair  wnere  tne  patn  description  contains  a  nonappiied  rule 
(the  final  rule)  to  a  pair  witn  all  rules  applied  and  a  new 
?oal  description.  This  is  tne  type  of  input  expected  by  tne 
function  BACKTRACK. 

b.   COMPOSE  Specification 

BACKTRACK  is  applied  to  eacn  <PATH,  GCAL>  pair 
produced  by  DECOMPOSE.  Tne  result  returned  by  tne 
application  is  a  sequence  of  paths.  Eacn  patn  represents  a 
sequence  of  rules  applied  to  tne  goal  description  wnicn 
terminated  in  a  solution.  For  ?oal  descriptions  which  could 
not  be  reduced  to  a  primitive  ^oal  tne  algorithm  returns  tne 
nil  path.  If  the  nil  path  is  found  in  tne  sequence  of  patns 
returned  it  signifies  that  one  of  tne  suoaroals  produced  cy 
the  reduction  rule  is  not  solvable.  From  our  discussion  of 
tne  problem  reduction  formalism,  tnis  means  that  the  goal  is 
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not  solvable  witn  mis  reduction  since  all  subgoals  produced 
must  be  solvel  to  solve  tne  £oai.  Tne  inference  is  mat  tne 
sequence  of  reduction  rules  wnicn  produced  tne  suogoais  does 
not  lead  to  a  solution  and  tne  nil  patn  must  oe  returned  to 
indicate  sued.  If  no  nil  patn  is  returned  in  tne  sequence 
then  all  subgoals  were  solved  and  tne  sequence  is  returned. 

Figure  14  depicts   tne   requirements   of   tne   lower 
level  functions  of  tne  problem  reduction  bacKtracK  scnema. 

D.   A  SIMPLE  ARITHMETIC  THEOREM  PROVER 

Our  example  to  illustrate  tnis  reduction  rule  is  tne 
simple  theorem  prover  developed  tnrou^nout  tnis  cnapter.  A 
formal  oroblem  specification  will  not  be  developed  as  tne 
informal  description  of  tne  reduction  is  not  detailed  enougn 
to  exploit  tne  formalism  of  a  specification.  Instead,  tnis 
paragraph  will  develop  informal  specifications  based  on  tne 
problem  representation  of  Figure  12  and  tne  function 
reauirements  of  Figure  14. 

1 .   GEN  ERA TE  Sp.ec.lf  1  cat  ion 

Our  problem   representation   lists   a   set   of   four 

reduction   rules,  R1...R4.  GENERATE  must  produce  a   sequence 

of  four  <PATK,  GOAL>  pairs.   Each  PATH  will  terminate  witn  a 

different   reduction   rule.   We   can   express   tnis  in   our 

informal  notation  as: 

GENERATE:<PATH,  GOAL>  =  «PATH(l),  GCAL> , <PATH (2 ) ,  GOAl>. 

<PATH(3),  GOAL>,<?ATH(4)  ,  GOAI>^> 
sucn  that 

TLR:PATH(i  )  =  PATH  6, 

TL:PATH(i)  =  RULE(i) 
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This   will   provide   the   lesired  input  to   the   conditional 
test. 


GENERATE  REQUIREMENTS 

GENERATE :<PATH,  GOAL>  =  NEV_STATE   sucn  that 
NEtf_STATE  =  {<NEtf_PATH,  GOAL>! 

NEW_PATH  =  APPENDR:<PATH,  RULE>  for  eacn  RULE) 

SOLUTION  REQUIREMENTS 

SOLUTIONtGOAL  =  boolean   such  that 

boolean  <=>  Rl :  PRIMITIVES ,  GOAL> 

vnere   Rl  is  a  problem  dependent  relation 

FEASIBLE  REQUIREMENTS 

FSASIBLE:<PATE,  GOAL>  =  boolean    sucn  that 
boolean  <=>  R2:  Ltlr  :PATH,  GOALJ 
wnere  R2  is  a  problem  aependent  relation 

DECOMPOSE  REQUIREMENTS 
DECOMPOSE:<PATP,  G0AL>  - 

<<?ATHt  NEW_G0AL(1  )>,...  ,<PATH,  NEW_GOAL ( N ) >> 
such  tnat 

[N  =  numDer  conjuncts  in  precondition  TL  :PATHJ  b. 
R2:<C0NJUNCT(i ) ,  NEW_GOAL(i)>  = 
R2: LtlrrPATH,  GOALJ   J 

COMPOSE  REQUIREMENTS 

COMPOSE:SOLUTION_SEQUENCE  =  SOLUTIONS   sucn  tnat 

[v»s^BER:<NILf  SOLUTION  SECUENCK>  => 

SOLUTIONS  =  NILJ  5, 
[NOT(MEMBER<NIL,  SOLUTION_SEQUENCE> )  => 

SOLUTIONS  =  SOLUTIONS  SEQUENCE] 


FIGURE  14 
Reduction  Rule  Requirements 


2.   SOLUTION  Specification 

Tne  major  difficulty  in  specifying  the  SOLUTION 
function  is  in  determining  tne  appropriate  relation  netween 
tne  primitive  rules  and  tne  goal  descriptior.  In  tne 
theorem  prover  problem  we   attempt  to  reduce  tne  initial  goal 
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iescriptions  to  descriptions  wnicn  are  Known  to  be  true. 
Tne  descriptions  Known  to  be  true  are  tne  problem 
propositions,  wfticn  tne  problem  representation  designates  as 
primitive  rules.   Tne  problem,   therefore,   is   to  rind  ,?oal 

descriptions  wnicn  are  in  tne  set  of  primitive  rules.   Tne 

appropriate  relation  is  a  membership  test  and  we  can  express 

tnis  as: 

SOLOTION:GOAL  =  boolean  sucn  tnat 

boolean  <=>  MEMBER  :GOAL,  PRIMITIVES>J 

3.   FEASIBLE  Specification, 

Tne  FEASIBLE  predicate  is  a  test  of  tne 
applicability  of  tne  final  rule  of  tne  patn  to  tne  current 
goal  description.  Tne  specification  question  is  to 
determine  wnat  relation  tests  tnis  applicability.  In  tnis 
problem  a  goal  description  is  given  in  terms  of  constants, 
literals  and  aritnmetic  operators.  Tne  rules  are  expressed 
in  terms  of  variables,  constants  ana  operators.  An 
appropriate  applicability  test  is  a  pattern  matcn  between 
tne  conclusion  of  tne  rule  and  tne  goal  aescription.  Tnis 
test  can  matcn  any  subexpression  or  literal  of  tne  goal 
against  tne  rule  variables,  but  tne  constants  and  operators 
must  be  exact  matcnes.  If  a  matcn  is  found  tne  rule  can  be 
applied  to  tne  soal.   Tnis  can  be  expressed  as: 

FEASIBLE: <PATH,  G0AL>  =  boolean   sucn  tnat 
boolean  <=>  MATCH:  [TL: PATE ,GOALj 
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4.  DECOMPOSE   ^edification 

After    ttte    predicate    FEASIBLE  nas   determine!    tnat    tne 

rule    applies    to      tne      sroal    description,    DECOMPOSE   must    apply 

trie    rule   and   construct   a    sequence    or   <PATH,      (iOAI>   pairs    for 

input    to    BACKTRACK.    To   determine    sube-oals    *e    note      tnat      tne 

precondition   of    tne    reduction   rule    lists      tne      form      of      tne 

subgoals      to      be      produced.  Tne      difficulty      in      creating 

subeoais    is    in    replacing   tne   rule   variables   witn    the   problem 

literals      and        subexpressions.  We        can        identify        tne 

appropriate   literals   witn     a     matcning     process   identical    to 

that    conducted    by   tne     feasibility      test.        For  ee.cn.   subgoal 

produced    DECOMPOSE   must    tnen   create   a    <PATH,    GOAI>   pair.      We 

can  express    tnese    requirements   as: 

DECOMPOSE  :<-?ATH,    SOAL>    = 

<<PATh\    NEW_G0AL(l )>,... ,<PATH,    NEW_GOAI(  N  )  >>      sum    tnat 
N    =   number   conjuncts    in   preconaition    of   TL:?ATn   ^ 
FOR   EACH      CONJUNCT(i)       IN         tirrPATF 
MATCE:<COMJUNCT(i)  ,    NEW_G0AL(iO    = 
MATCH:[tlr:?ATH,    GOAL 

5.  COMPOSE   Specification 

Tne    final    function    to    specify    is      COMPOSE.      Tnis      is 

also    tne   simplest    to    specify.      COMPOSE   must      return      nil      if 

nil    is    a   member   of    the      parameter   sequence.      If    nil    is    not   a 

member   of   tne    sequence    tnen    tne   sequence    is      to    ce    returned. 

Tnis   can   be   expressed   as: 

COMPOSE:SOLOTION_SEOUENCE    =   RETTJRN_S  EOUENCE      sucn    tnat 
[M£MBER:<NIL,    SOLUTION_SECUENCE>    => 

RETURN_SEC'JENCE    =    NILJ    6, 
[NOT(ME"BER:<NIL,    SOLUTICN_SECUENCE>)    => 

RETURN    SEQUENCE    =    SOLUTION    SEQUENCE] 
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Tne   complete   informal  specification  for  tne   functions   is 
?iven  at  FIGURE  lb. 
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PROOFKGOAL,  PRIMITIVES,  RUL£S>  = 

EACKTRACKKNIL,  GOAL> 
wftere 

BACKTRACK:<PATH,  GOAL>  = 
/APPEND 
(<X(iambaa<PATH> 

{(SOLUTION 2 GOAL  ->  ID:?ATH; 
FEASIBLE: <PATH,GOAL>  -> 

COMPOSE(  BACKTRACK(DECOMPOSE:<PATfl,GOAL>)  )J 
NIL^}) 

(GENERATE :<PATHf  GOAL>  )  ) 

GENERATE:<PATHt  GOAL>  = 

<<PATH(l),  GOAL>,  ...  ,<PATH(4),  GOAL>> 
sucn  tnat   FOR  ALL  PATRfil 

[TLR:PATH(i )  =  PATH    & 
TL:PATH(i)   =  RULE(i  )J 

SOLUTION :G0AL  =  boolean     sucn  tnat 

boolean  <  =  >  "EMBER  :<GOAL ,  PRIMITIVES> 

FEASI£LE:<PATH,  GOAL>  =  boolean    sucn  tnat 
boolean  <=>  MATCH :  [TL:PATH ,  GOALJ 

DECOwpoSE:<PATHf  GOAL>  = 

<<PATHt  NE'rf_GOAL(l )>,... ,<?ATH,  NEV_GOAL( N )>> 
sucn  tnat 

[N  =  number  conjuncts  in  precondition  tl:PATH   6. 
FOR  EACH   CONJUNCT(i)   IN   tlrtPATH 
*ATCH:<CONJUNCT(i)  ,  NEW_G0AL(i)>   = 
MATCH: [tir:PATHt  GOALJ 

COMPOSE: SOLUTION_SEOUENCE  =  RETURN     sucn  tnat 
[MEMSSR:<NILf  SOLUTION_SEQUENCE>  => 

RETURN  =  NIL     & 
N0T(V,EMEER:<NIL,  SOLUT  ION_SEQUEN  CE>  )  => 

RETURN  =  SOLUTION  SEQUENCE] 


FIGURE  15 
Tneorem  Prover  Program  Soecif ication 
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71.  CONCLUSION 

The  success  of  future  efforts  in  program  synthesis  will 
lepend  in  large  part  on  tne  ability  of  system  developers  to 
codify  expert  Knowledge  about  tne  programming  process.  As 
syntnesis  systems  become  more  complex  and  attempt  to  solve 
more  difficult  problems  tne  searcn  space  create!  in  the 
solution  process  suffers  tne  effects  of  combinatorial 
explosion.  As  tne  searcn  space  stows  tne  search  strategy 
must  become  more  efficient.  Tne  larger  tne  space  tne  closer 
tne  searcn  process  must  approximate  a  strai^nt  line  searcn. 
Tne  ability  to  execute  a  straignt  line  searcn  is  a  function 
of  the  Knowledge  the  search  strategy  employs  to  soive  tne 
problem.  The  better  tne  Knowledge,  tne  fewer  incorrect 
alternatives  will  be  explored. 

Tne  principal  goal  of  tnis  paper  is  the  development  ov  a 
reduction  rule  for  a  svntnesis  system  based  on  the  problem 
reduction  representation  formalism.  Tnis  rule  encapsulates 
specific  Knowledge  about  now  to  solve  a  class  of 
combinatorial  problems.  It  includes  a  control  strategy 
based  on  tne  bacitracfc  class  of  algorithms  and  a  lesign 
method  for  developing  subproblem  specifications  which,  when 
solved,  can  be  incorporated  into  tne  control  strategy  to 
solve  tne  original  problem.  It  is  believed  that  tne  design 
metnoi  is  sufficiently  specific  to  sruine  tne  syntnesis 
process  tnrougn  the  first  level  specification  of  any  problem 
in  its  class. 
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Trie  secondary  goal  of  tnis  paper  is  tne  refinement  of 
eeneral  programming  Knowledge  concerning  me  bac-Ktracic 
control  structure.  It  is  believed  tnat  current  Knowledge 
concerning  tne  strategy  is  deficient  in  two  areas.  While 
tne  backtrack:  procedure  ftas  been  schematized,  general 
principles  concerning  tne  relationships  between  tne 
components  of  tne  procedure  nave  not  been  ~learly 
articulated.  Tne  design  alternatives  for  tne  lower  level 
functions  nave  not  been  specified  and  tne  reiationsnip  of 
tne  functions  to  tne  problem  nas  not  been  defined.  It  is 
believed  tnat  tne  reduction  rule  of  Cnapter  IV  can  provide  a 
design  basis  for  programmers  as  well  as  a  syntnesis  system. 

The  second  area  of  Knowledge  refinement  concerns  tne 
extension  of  tne  basic  strategy  to  a  problem  domain  to  whirrn 
it  nas  not  been  previously  applied.  Cnapter  V  adapts  tne 
basic  strategy  to  searcn  tne  &ND/OR  grapns  produced  by  a 
problem  reduction  representation  formalism.  Tne  informal 
reduction  rule  developed  in  tnis  cnapter  can  again  be 
applied  by  programmers  as  a  basis  for  design. 

Tne  bacKtracn  strategy  is  clearly  not  tne  most  efficient 
tecnnique  for  searching  state  space  or  ANT/OR  trees. 
Whenever  problem  area  Knowledge  can  be  codified  for  use  by  a 
control  strategy,  a  searcn  process  wnicn  selects  a  best  patn 
for  expansion  will  be  more  efficient  tnan  a  bacfctracx 
searcn.  In  many  cases  it  is  eitner  not  possible  to  coaify 
sucn  Knowledge  in  an  efficiently   computable  format  or  tne 
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ssarcn  efficiency  is  not  wortn  tne  added  effort  of  including 
trie  Knowledge.   Tne  bacKtracu:   strategy  offers  an  attractive 

option.  Witft  readily  avaiiaDle  program  s~nemas  and  design 
.•net nods  tne  control  strategy  is  easily  developed.  Once 
developed,  tne  strategy  can  significantly  prune  a  searcn 
tree  provided  problem  constraints  are  sufficiently 
restrictive.  Tnis  places  empnasis  on  rigorous 
identification  and  specification  of  tne  problem  constraints, 
an  activity  beneficial  to  programming. 

Tnere  are  significant  researcn  areas  remaining  to  be 
investigated.  These  include  a  formal  proof  of  tne  reduction 
rule  proposed  in  Cnapter  IV,  formalizing  tne  rule  proposed 
in  Cnapter  7  with  a  formal  proof,  investigation  of 
efficiency  improving  constraint  allocation  tecnniques  for 
tne  lower  level  functions  FEASIBLE,  SOLUTION  and  GENERATE, 
and  otner  design  metnods  for  tne  bacKtraci  strategy  cased  on 
different  assumptions  tnan  tnose  discussed. 
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APPENDIX  A  -  THE  PROGRAMMING  LANGUAGE 

Tne   following  is   a  description   of   tne  programming 

laneuaee  used  in  tne  definition  of  tne  program  s~nemas   and 

developed   examples.   Tne  descriptive  format  and   mo^t 
definitions  are  derived  from  Bacius  LHef.  xxj  . 


A.  THE  SET  OF  OBJECTS  ANT  TYPES 


UBS 

B 

N 

I 
LIST(N) 

<> 


description 

boolean  values 

natural  numbers 
integers 

lists  of  natural 
numbers 

sequence  of  objects 


example  values 

true 
false 

0   12 

nil 

(1) 
(1,2,3) 

<nil> 

<1,  3,  true,  (2?3)> 


£.   THE  SET  OF  FUNCTIONS 


function   domain 


s:x 


tl:x 


id:x 


anv 


any 


any 


IJJ1£§. 


any 


any 


any 


lef ini tion 

if   x=<xl , . . . ,  xn> 
and  n  >=  s 

tnen  xs 

else  undefined 

if   x=<xl> 
tnen  <nil> 
if   x=<xl , . . . , xn> 
and  n>=2 

tnen  <x2, . . . ,xn> 
else  undefined 
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function        domain  ran?? 

atomrx  any  B 


equal  :x 


null  :x 


+  :x 


-:x 


anl  :x 


or  :x 


NxN 


nequal :x        NxN 


LIST(N)         B 


lenfftnrx        LIST(N)        N 


NxN 
NxN 
SxB 

Sx3 


appendr:x      any 


appendlrx      any 


N 


E 


any 


any 


\ 


iS.Iini  lion 

if      xBorxN 
tnen    true 
else  false 

if   x=<y,  z> 

anl  y=z 
tnen  true 
else  false 

if   x=<y,z> 

and  y=z 
tnen  false 
else  true 

if  x=nil 
tnen  true 
else  false 

if   x=nil 

tften  0 

if  x=<xl , . . . ,xn 

tnen  n 

if   x=<y,z> 
tnen  y*z 

if   x=<y,z> 
tnen  y-z 


if   x=<true,  true> 
tnen  true 
else  false 

if  x=<false,  false> 
tnen  false 
else  true 

if   x=<nil,  z> 

tnen  <z> 

if   x=<(xl ♦ .  . . ,xn) ,  z> 

tnen  <xl, . . . ,xn. z> 

else  undefined 

if   x=<z,  nil> 

tnen  <z> 

if  x=<z ,  (xl, . . . ,xn)> 

tnen  <  z  ,xl xn> 

else  undefinea 


-- 


Lu.HQ.Il°H   dom_aJ,a    lings 
append:x   any       any 


tlr:x 


aos  :x 


any 


any 


N 


If  x=<z,  nil> 

or  x=<nllfzs 
tnen  <z> 
If  zs<z,(zl,...vxn)> 

men  <z,xl,...,xn> 
else  undefined 

If  x=<xl> 
then  <nil> 
if   x=<xl , . . . , xn> 

ana  n>=2 
tnen  <xl,  . .  .  ,  xm^> 

wnere  m=n-l 
else  undefined. 


1  T  ' 


note:  tne  result  of  functions  applied  to   invalid  types   is 
undefined 


C.   THE  APPLICATION  OPERATION 

Tne  application  operation  allows  tne  use  of  na^ed 
parameters.  Function  definitions  include  formal  parameter 
names.  Tne  scope  of  tnese  names  is  restricted  to  tne 
function  application.  Tne  actual  parameter/formal  parameter 
correspondence  is  positional.  If  a  single  actual  parameter 
is  required  tne  syntax  is  as  follows: 

function_name :parameter 
If  multiple  parameters  are  required,  tney  are   listed   as   a 
sequence  as  follows: 

func tion_name:<parameter_l ,  ...  , parameter. 


n> 


D.   THE  SET  OF  COMBINING  FORMS 


form 
f  (  ?  :  x  ) 


name 
composition 


ilsilini.ti  on 
f :<^:x> 
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form  HiE° 

[fl,  ...  ffnJ:x   construction 

(p:x  f:yj?:z)     condition 


/f  :x 


f  :x 


insert 


apply  to  aii 


defini tion 

<fl :x ,  ...  ,fn:x> 

If  p:x 

t  n  e  n  fry 

else  g :  z 

vnere  x,y,z  are  narred 
parameters  not  necessarily 
distinct 

if   x=<xl> 

tnen  xl 

if   x=<'xl ,  ...  ,xn> 

tnen  f:<xl,  /f :<xl , . . .  ,  xn>> 

else  undefined 


if   x=nil 
tnen  nil 
if   x  =  <xl ,  .  . 
tnen  <f :xl ,  . 


.xn> 

. .  ,  f  :  x  n  > 


function 


E.   THE  FUNCTION  DEFINITION  MECHANISM 

Tne   operator   binds   a   function   name   to   a 

definition.   Tne  syntax  is  as  follows: 

function  name: <parame ter  iist> 

function  definition 

The  language   also  permits  tne  use  of  anonymous  function 

definitions.   Tne   lamoda  operator  is  used   to  define   tne 

function  as  follows: 

(lamoda  ^parameter  list> 

{function  definition}) 
(actual  parameter  iist^ 
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